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FOREWORD 


This  report  attempts  to  lay  foundations  for  a  total  ship  system  engineering 
process.  It  results  from  a  continuing  effort  to  construct  elements  of  a  vision  and 
strategy  for  improving  the  total  life  cycle  effectiveness  of  surface  combatants  in  the 
21st  century.  The  aim  is  to  articulate  a  disciplined,  top-down  approach  that  stimulates 
consideration  of  new  technologies  and  new  ways  of  doing  business. 

The  effort  benefits  greatly  from  the  guidance  provided  by  a  group  of  key  Navy 
acquisition  executives,  working  together  as  a  team  to  prepare  the  way  for  a  new 
generation  of  world  class  surface  combatants.  Contributing  activities  have  included 
AEGIS,  Cruise  Missiles  and  Unmanned  Aerial  Vehicles,  Theater  Air  Defense,  Undersea 
Warfare,  PD-60  and  PD-70  of  the  Space  and  Naval  Warfare  Systems  Command,  and 
the  Engineering  Directorate  of  the  Naval  Sea  Systems  Command.  The  flag-level 
members  were  supported  by  an  administrative  team  drawing  from  their  staffs  as  well  as 
the  Naval  Surface  Warfare  Center  (NSWC)  and  the  Naval  Command,  Control  and 
Ocean  Surveillance  Center.  Known  to  each  other  as  the  “Gang  of  Six,”  this  group  has 
provided  strong  support  to  the  idea  of  building  a  culture  of  teamwork  that  overcomes 
the  stovepiping  of  the  past. 

Several  related  efforts  must  be  acknowledged.  Substantial  help  was  obtained 
from  the  Surface  Combatant  21st  Century  (SC-21)  War  Room  at  NSWC  Dahlgren 
Division,  led  by  John  Burrows  and  sponsored  by  Rear  Admiral  George  Huchting,  USN. 
The  Naval  Air  Warfare  Center’s  Training  Systems  Division  and  the  Naval  Postgraduate 
School  at  Monterey  have  also  contributed.  Another  is  a  strategic  thrust  by  NSWC  to 
provide  a  capability  for  the  Navy  to  engineer  ships  as  systems.  The  Carderock  Division 
is  hosting  this  effort,  in  which  all  divisions  of  NSWC  are  involved. 
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EXECUTIVE  SUMMARY 


A  number  of  serious  difficulties  must  be  overcome  to  meet  the  emerging 
challenges  of  the  21st  century.  First,  we  face  an  era  of  austerity  and  change  as 
US  forces  are  downsized.  Second,  we  also  face  considerable  uncertainty  due  to  the 
diversity  of  threats  and  environments  which  could  arise  in  future  conflicts.  Third,  it  must 
be  recognized  that  revolutionary  changes  are  taking  place  in  warfighting  systems  and 
methods.  Given  the  complexity  of  warfare  tasks,  superior  system  engineering  will  be 
needed  to  create  new  combatants,  tailored  to  the  joint  and  expeditionary  warfighting 
concepts  now  beginning  to  emerge.  For  all  these  reasons  it  is  necessary  to  prepare  the 
way  for  a  new  generation  of  world  class  naval  combatants. 

This  report  is  based  on  the  premise  that  future  Navy  ships  should  be  engineered 
from  a  total  ship  perspective  to  serve  as  elements  of  a  capable  and  jointly  interoperable 
Navy  warfighting  system.  Chapter  1  reviews  the  basic  concept  of  total  ship 
engineering:  that  is,  a  warship  must  act  as  a  coherent  warfighting  system,  all  parts 
working  in  unison  to  maximize  operational  effectiveness.  From  the  hull  form  to  the 
launchers  and  missiles,  every  part  of  the  ship  must  contribute  to  the  overall  goal  of 
ordnance  on  target. 

Chapter  2  gives  the  basics  of  a  system  engineering  approach  to  total  ship 
engineering.  System  engineering  is  a  robust  approach  to  design,  creation,  and 
operation  of  complex  systems.  Applied  to  surface  combatants,  a  suitable  system 
engineering  process  will  integrate  ship  design,  construction,  and  support  activities  over 
the  entire  value  stream.  The  idea  is  that  future  ships  must  weave  combat,  support,  hull, 
and  machinery  modules  into  a  "system  of  systems"  configuration  with  a  mix  of 
firepower,  stealth,  survivability,  and  affordability  characteristics  that  meets  all 
operational  requirements.  This  demands  efforts  to  establish  a  comprehensive  system 
engineering  framework  for  ships. 

Chapter  3  considers  elements  of  a  control  architecture  for  surface  combatants. 

It  constructs  a  process  reference  model  for  the  surface  ship  domain,  indicating  that 
control  structure  drives  the  ship’s  ability  to  act  as  a  coherent  entity.  The  process 
reference  model  captures  basic  missions  and  operating  concepts,  defines  key  technical 
concepts,  and  provides  a  vocabulary  that  will  permit  sharing  of  ideas  throughout  the 
Navy  community.  Building  blocks  for  such  models  include  elementary  sense,  control, 
act  operations  and  three  types  of  interconnecting  paths.  Action  paths  sequence  basic 
operations  to  perform  mission  tasks.  Information  paths  represent  data  flows,  while 
command  paths  represent  lines  of  authority  and  responsibility.  These  are  the  basic 
intellectual  tools  necessary  to  arrive  at  a  clear  understanding  of  what  surface 
combatants  are,  what  they  must  do,  and  how  they  should  be  built. 
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Chapter  4  considers  what  the  control  structure  of  a  surface  ship  should  be,  from 
a  top-down  perspective.  The  strategy  for  partitioning  control  resources  on  a  total  ship 
basis  is  rooted  in  basic  principles  of  system  engineering.  The  first  principle  to  be 
considered  is  that  the  aim  of  design  must  be  to  help  the  warfighters  in  achieving  their 
operational  objectives.  The  mission  teams  carried  to  an  operating  area,  where  they 
may  be  called  upon  to  maintain  presence  or  to  deliver  high-tech  firepower  against  an 
adversary,  must  be  the  primary  concern. 

At  this  point  the  overall  control  problem  is  broken  down  into  a  relatively  small 
number  of  backbone  areas  (or  core  subsystems).  Three  backbones  are  considered 
necessary:  one  to  control  mission  operations,  a  second  for  plant  control  and  readiness, 
and  a  third  for  management  of  information  flows.  The  mission  operations  and  plant 
control  areas  reflect  the  traditional  partitioning  of  combat  from  hull,  mechanical,  and 
electrical  systems.  However,  both  are  seen  as  total  ship  constructs  and  it  is  recognized 
that  in  future  ships  the  position  of  the  boundary  may  change.  Maneuver  and  damage 
control  coordination  are  seen  as  increasingly  important  concerns  that  may  move  across 
the  boundary.  The  third  backbone  area,  information  management,  recognizes  that 
information  is  a  resource  that  must  be  coordinated  on  a  shipwide  basis  and  that  special 
attention  may  be  needed  to  create  the  necessary  means  for  coordination. 

The  approach  to  partitioning  represents  a  critical  step  in  total  ship  system 
engineering.  A  decision  must  be  made  very  early  in  the  process,  and  it  is  all  too  easy 
to  find  convenient  pieces  without  establishing  clearly  how  they  will  work  together  to  form 
a  well-integrated  operating  entity.  The  structure  identified  at  this  point  serves  as  a 
framework  for  defining  and  controlling  the  process  of  top-down  system  engineering. 

Chapter  5  considers  a  development  process  matched  to  the  desired  control 
architecture  and  reflecting  an  enterprise  strategy  for  total  ship  system  engineering.  The 
chief  concern  in  process  definition  is  to  ensure  all  major  design  decisions  are  based  on 
what's  best  in  terms  of  overall  warfighting  capability,  rather  than  what's  best  for  any 
particular  component  or  class  of  systems.  This  makes  total  ship  system  engineering  as 
much  a  process  control  or  coordination  problem  as  it  is  a  technical  problem.  Overall, 
four  main  points  are  developed. 

•  The  development  organization  must  be  tailored  to  the  desired  architecture  and 

engineering  process. 

The  main  features  of  the  development  organization  are  based  on  the  system 
engineering  principle  that  work  units  should  be  organized  around  the  loosely  coupled 
subsystems  formed  by  partitioning.  The  implication  is  that  a  partitioning  for  total  ship 
design  must  be  driven  first  and  foremost  by  operational  considerations,  and  the 
development  team  structured  accordingly,  rather  than  the  other  way  around.  The  first 
concern  must  be  to  ensure  that  a  basic  understanding  of  mission  teams  and  tasks  is 
established.  The  development  team  must  then  address  overall  ship  design,  the 
definition  of  backbone  control  structures,  and  the  definition  of  specific  operating 
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processes,  adequate  to  meet  all  mission  needs.  These  represent  the  principal 
components  of  the  projected  development  team.  Each  component  will  make  a  key 
contribution  to  creation  of  a  total  ship  “system  of  systems”  from  the  host  of  individual 
systems  delivered  to  the  shipyard.  Because  it  must  deal  with  acquisition  and 
integration  of  individual  systems  as  well  as  overall  ship  construction,  team  structure  is  a 
bit  more  complicated  than  the  operational  control  structure. 

Designers  and  builders  of  future  naval  combatants  must  escape  from  stovepipe 
thinking  and  learn  to  rely  on  global  or  team  thinking.  The  development  organization 
should  be  structured  to  maximize  value  delivered  to  mission  teams  on  a  life  cycle  basis. 
The  team  leader  activity  is  expected  to  control  the  overall  design  process,  including 
weight,  space,  and  cost  budgets;  the  strategy  for  integration  and  control  of  mission 
capabilities;  and  creation  of  the  mission  critical  systems  that  are  the  reason  for  taking 
the  ship  to  sea.  The  supply  chain  should  be  structured  to  take  advantage  of  the  best 
practices  devised  by  firms  around  the  world.  Open  specifications  would  be  used  and 
Information  relating  to  process  improvement  (best  practices)  would  be  shared. 
Transactions  among  team  members  should  be  observed  to  identify  opportunities  for 
gains  in  productivity. 

•  A  unifying  sense  of  purpose  and  direction  must  be  created  to  knit  the  people 

involved  into  an  effective  team. 

The  first  and  most  important  step  is  probably  to  form  a  cadre  that  is  able  to 
consider  tradeoffs  from  a  total  ship  perspective.  This  calls  for  a  broader  perspective 
than  usual,  but  one  with  a  full  appreciation  for,  and  easy  access  to,  the  specialized 
technical  knowledge  of  functional  activities  and  the  warfighting  community.  In 
particular,  some  way  must  be  found  to  foster  and  control  dialog  between  the  different 
engineering  disciplines  involved. 

It  is  difficult  to  create  a  foundation  for  total  ship  system  engineering  that  spans  all 
the  disciplines  (technical  and  operational)  involved.  The  trouble  is  that  each  discipline 
has  its  own  conceptual  framework,  tailored  to  the  goals,  values,  and  character  of  its 
work  and  fundamental  to  effective  teamwork.  This  framework  is  passed  to  each 
generation  of  recruits  and  colors  perception  of  new  ideas,  sometimes  making  them 
seem  irrelevant  or  contrary  to  accepted  methods  or  bodies  of  knowledge.  Fortunately, 
this  is  an  obstacle  that  can  also  be  a  solution;  that  is,  an  appropriate  conceptual 
framework  can  be  established  to  support  total  ship  system  engineering.  In  essence, 
this  report  is  aimed  at  producing  such  a  framework,  with  associated  design  concepts, 
standards,  and  tools. 

•  Backbones  are  the  key  to  building  warships  as  systems. 

A  key  aspect  of  modern  technology  is  the  potential  for  gains  in  capability  and 
affordability  through  sharing  of  resources  across  subsystem  and  element  boundaries. 

A  wide  variety  of  resources  (sensors,  computers,  and  displays;  magazines  and 
launchers)  can  be  shared  in  this  way.  For  this  reason  the  key  problems  of  design  are 
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moving  upward  in  the  hierarchy  of  systems,  and  formal  trade  studies  become 
necessary  for  novel  partitionings  of  embedded  combat  and  ship  systems. 

•  Warfighters  must  be  involved  in  the  development  process. 

Flexibility  is  a  major  consideration  in  building  forces  to  cope  with  an  uncertain 
future.  The  hope  is  that  flexibility  will  enable  US  forces  to  respond  quickly  to  emerging 
threats,  extend  US  reach  to  any  part  of  the  globe,  and  adopt  new  technologies  with 
ease.  Having  acknowledged  the  importance  of  flexibility,  many  look  to  computers  and 
automation  as  the  key  to  improvement.  However,  the  brilliance  of  the  technology  tends 
to  obscure  the  importance  of  articulating  precisely  what  kind  of  flexibility  is  necessary 
and  defining  a  strategy  for  achieving  it.  The  bulk  of  lessons  learned  from  industry 
efforts  at  flexibility  improvement  via  computer  integration  indicate  that  success  depends 
more  on  people  than  any  technical  factor. 

We  know  for  certain  that  experienced  teams  can  handle  a  wider  range  of  tasks 
than  novice  teams,  but  even  experienced  teams  can  have  difficulty  adapting  to  change. 
In  particular,  leadership  appears  to  play  a  key  role  in  identifying  the  kind  of  flexibility 
needed  and  when  it  is  appropriate.  This  is  fundamental  in  a  practical  approach  to 
automation.  What  seems  most  promising,  for  improved  flexibility,  is  not  automation  to 
replace  people,  but  automation  that  helps  people  in  tailoring  systems  and  procedures  to 
the  changing  conditions.  To  that  end,  it  is  essential  to  have  direct  involvement  by 
experienced  mission  teams  in  surface  ship  design  and  development. 
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CHAPTER  1 
INTRODUCTION 


A  number  of  difficulties  must  be  overcome  to  meet  the  emerging  challenges  of 
the  21st  century.  First,  we  face  an  era  of  austerity  and  change  as  US  forces  are 
downsized.  We  also  face  many  uncertainties  due  to  the  diversity  of  threats  and 
environments  that  must  be  expected  in  future  joint  and  expeditionary  warfare 
operations.  At  the  same  time,  we  must  recognize  that  this  is  an  era  of  rapid  change  in 
warfare  systems  and  methods.  The  mix  of  capability,  versatility,  and  affordability 
characteristics  envisioned  for  new  combatants  will  call  for  new  levels  of  engineering 
achievement.  Given  the  complexity  of  warships,  this  demands  nothing  less  than  a 
comprehensive  reengineering  of  the  process  by  which  operational  requirements  are 
transformed  into  new  combatants.  Both  problems  of  current  practice  and  emerging 
opportunities  must  be  considered  in  framing  this  task. 


EVOLUTION  OF  THE  SHIP  ACQUISITION  PROCESS 

Today’s  ship  design,  acquisition,  and  construction  process  is  the  end  result  of  a 
long  evolutionary  chain.  The  overall  structure  of  the  process,  its  history,  and  the 
underlying  concept  of  organization  are  considered  in  References  1  through  1 7.  Over 
the  years,  the  Navy  has  experimented  with  many  different  approaches  to  ship  design, 
as  shown  especially  in  References  2,  3,  14,  and  17.  Stovepiping*  and  the  growing 
complexity  of  modern  systems  have  been  important  concerns  throughout  this  period. 

Ship  design  and  acquisition  functions  were  managed  in  much  the  same  way  from 
the  1920s  until  about  1966.  Ship  design  functions  were  performed  in  house  and  some 
construction  was  also  performed  in  house,  at  naval  shipyards.  Feasibility  studies, 
preliminary  design,  and  contract  design  were  done  by  the  Bureau  of  Ships  (BUSHIPS) 
design  division.  The  problem  of  managing  ship  construction  was  then  turned  over  to  a 
type  desk,  which  handled  all  ships  of  a  particular  type,  such  as  destroyers.  BUSHIPS 
had  been  formed  by  merging  the  Bureau  of  Construction  and  Repair  with  the  Bureau  of 
Engineering  in  1940  and  was  fairly  stable  from  1940  to  1958.  The  first  major 
reorganization  took  place  with  the  DoD  Reorganization  Act  of  1958.  Reference  1  states 
that  one  of  the  key  objectives  was  to  “...complete  evolution  of  the  Ship  Design 


*  The  purpose  of  a  stovepipe,  in  conventional  usage,  is  to  separate  the  exhaust  gas  flows  from  the  other 
air  flows  around  a  stove.  By  analogy,  a  process  is  said  to  be  stovepiped  when  it  is  isolated  from  other, 
similar  processes.  Use  of  the  term  suggests  a  lack  of  proper  coordination. 


1 


NSWCDD/TR-95/152 


organization  along  functional  lines.”  The  idea  was  to  bring  the  machinery  and 
electronics  disciplines  into  preliminary  design,  which  until  then  had  remained  a  naval 
architecture  preserve.  The  Bureau  of  Weapons  was  also  formed  at  this  time,  by 
merging  the  Bureau  of  Ordnance  and  the  Bureau  of  Aeronautics.  Both  changes  were 
intended  to  deal  with  stovepiping  concerns. 

The  advent  of  total  package  procurement  in  the  mid-1960s  brought  further 
changes  to  the  ship  design,  acguisition,  and  construction  process.  Following  a  critical 
review  of  ship  design  and  integration  procedures  by  the  National  Academy  of  Sciences 
in  1966,  a  project  management  approach  was  introduced  for  the  LHA,  DD  963,  and 
CGN  38  programs.  The  total  package  procurement  policy  led  to  use  of  private 
shipbuilders  for  design  of  these  ship  classes.  In  addition,  the  use  of  public  shipyards 
for  new  construction  was  eliminated. 

1970  brought  a  return  to  in-house  ship  design  with  a  central  design  management 
organization  in  the  Naval  Ship  Engineering  Center  (NAVSEC).  Total  package 
procurement  came  to  an  end  because  it  was  difficult  to  stabilize  requirements,  the 
process  was  vulnerable  to  buy-in,  and  the  most  cost-effective  solution  too  often  turned 
out  to  be  one  with  a  very  high  unit  acquisition  cost.  Although  ship  design  was  brought 
into  NAVSEC,  the  USS  PERRY  Class  (FFG  7)  became  the  first  design-to-cost  ship. 


RETURN  TO  TOTAL  SHIP  ENGINEERING 

A  growing  Soviet  naval  threat,  together  with  a  series  of  controversial  shipbuilding 
claims,  led  to  formulation  of  a  new  Naval  Sea  Systems  Command  (NAVSEA)  ship 
design  strategy  for  the  1980s.  Acquisition  streamlining  became  a  major  theme  for  the 
decade,  a  trend  which  continued  into  the  90s  with  commercialization  and  Defense 
Acquisition  Reform.  However,  NAVSEA  concluded  in  1986  that  the  necessary  level  of 
total  ship  engineering  had  not  been  reached.  Similar  conclusions  were  reached  in  two 
1988  studies  (see  References  10  and  11).  The  conclusions  are  illustrated  by  a 
comparison  between  USS  FLETCHER  (DD  445)  and  USS  ARLEIGH  BURKE  (DDG  51) 
classes  of  destroyers.  Though  separated  by  50  years,  both  designs  reflect  the  idea  that 
a  warship  should  be  regarded  as  a  weapon  system  (every  part  contributing  to  ordnance 
on  target).  But  many  designs  produced  in  the  intervening  50  years  did  not  achieve  the 
same  quality  of  integration,  and  even  in  DDG  51,  major  advances  were  noted  only  in 
fire  control. 

Both  ships  and  aircraft  are  used  to  carry  and  operate  combat  systems,  both  have 
commercial  counterparts,  and  both  involve  fluid  dynamics  and  structures.  Hence 
comparisons  are  often  drawn.  But  we  don’t  buy  ships  and  aircraft  in  the  same  way.  We 
buy  ships  more  like  buildings:  we  get  an  architect  to  design  what  we  think  we  want, 
choose  a  builder,  and  construct  relatively  few  units  to  any  given  design  (10  versus  100). 
At  its  worst,  this  approach  can  mean  buying  combat  systems  somewhat  like  furniture, 
as  something  that  adds  little  real  value  to  the  building  but  makes  it  easier  to  attract 
tenants.  At  best  it  turns  into  what  may  be  called  the  bottom-up  approach.  Given  a 
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desired  set  of  combat  systems,  the  ship  design  team  proceeds  to  wrap  a  suitable  hull 
around  it  and  stuff  all  of  the  necessary  machinery  and  accommodations  inside.  The 
combat  systems  are  treated  as  government-furnished  equipment  (GFE)  items  provided 
by  an  array  of  largely  independent  programs.  Construction  proceeds  from  the  keel  up 
by  a  process  of  component  assembly  and  integration.  Total  ship  engineering,  in  this 
context,  means  ensuring  that  appropriate  ship  elements  are  selected  and  effectively 
and  efficiently  combined  to  meet  design  requirements.  The  ship  designers  serve  as 
integration  agents,  providing  the  physical  interfaces  (spatial,  mechanical,  and  electrical) 
necessary  to  package  stand-alone  component  systems  into  the  hull.  Operator 
interfaces  are  determined  by  the  GFE  installed,  and  little  attention  is  given  to  integration 
across  mission  area  lines.  As  in  the  domain  of  buildings,  none  of  the  parties  involved 
has  a  strong  incentive  to  maintain  an  R&D  capability,  so  efforts  to  develop  and  apply 
ship  technologies  are  hampered.  In  addition,  the  bottom-up  approach  is  costly  in  terms 
of  acquisition,  manning,  and  logistics  support. 


DEALING  WITH  COST  FACTORS 

With  respect  to  cost,  the  problem  is  that  none  of  the  parties  involved  has  a  real 
grip  on  total  acquisition  cost  (end  cost).  The  NAVSEA  Chief  Engineer  in  June  1990 
initiated  an  effort  to  improve  quality  of  future  ship  designs,  to  reduce  ship  construction 
and  life  cycle  costs,  and  to  reduce  time  required  to  deliver  the  lead  ship  of  a  class. 
Results^"  suggest  there  is  limited  potential  for  reducing  end  cost  (total  acquisition  cost) 
by  changes  in  the  shipbuilding  process  alone.  In  modern  warships  the  combat  system 
may  account  for  60  percent  or  more  of  end  cost.  Handled  as  GFE,  this  part  of  end  cost 
is  not  under  a  shipbuilder’s  direct  control.  Planning  and  change  orders  accounting  for 
another  15  to  25  percent  are  outside  the  builder’s  direct  control.  Perhaps  only  about  15 
percent  of  end  cost  can  be  leveraged  by  changes  in  the  shipbuilding  process. 

What  is  needed  is  a  disciplined  system  engineering  approach  in  which 
affordability  and  capability  are  considered  as  two  sides  of  the  same  coin  (i.e.,  a  strong 
Fleet).  Such  a  strategy  is  outlined  in  Figure  1.  The  pie  chart  applies  to  life  cycle  cost 
(LCC)  for  a  typical  ship  as  given  by  Reference  18.  The  pieces  will  vary  in  relative  size 
for  each  ship  type  and  class.  One  of  the  larger  pieces,  personnel  cost,  can  be 
addressed  by  automation  and  by  process  reengineering.  Although  the  original  data 
applies  to  the  ship’s  crew,  it  should  be  recognized  that  ashore  personnel  costs  are  also 
a  major  contributor.  Other  areas  can  be  addressed  by  exploiting  commercial  products 
and  by  reinventing  development  and  support  processes.  While  improved  productivity  in 
shipbuilding  and  construction  should  be  sought,  broad  gains  can  be  achieved  only  by 
considering  the  entire  value  stream.* 


*  A  process  involves  a  group  of  activities  working  together  to  supply  a  good  or  service.  Each  activity 
performs  some  function  on  a  set  of  inputs  in  order  to  add  something  to  the  value  of  the  good  or  service 
delivered.  Ordered  by  completion  time,  the  activities  associated  with  a  given  process  can  be  thought  of 
as  a  sequence  of  value-adding  steps,  or  a  stream  of  values. 
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Wustrative  LCC  Breakdown  -  Naval  Ship 


•  Exploit  technology  to 
reduce  personnel  costs 

•  Exploit  commercial 
technology  in  acquisition 

•  Re-invent  development 
and  support  processes 


•  Seek  productivity  gains 
in  shipbuilding 


Design  2%  Fuel  4% 


FIGURE  1.  STRATEGY  FOR  AFFORDABILITY 

In  particular,  combat  capabilities  continue  to  have  an  important  place  in  the 
overall  value  stream.  The  progress  noted  by  Reference  10  was  achieved  only  by  great 
effort,  but  many  believe  the  era  of  rapid  and  fundamental  change  in  warfighting  systems 
and  methods  we  now  face  will  require  much  greater  effort.  Surface  combatants  carry  a 
mix  of  weapon  systems,  usually  developed  by  different  programs  to  different  protocols 
and  standards,  and  creation  of  a  well-integrated  combat  system  involves  a  major  effort. 
In  fact,  the  effort  necessary  to  create  unique  integration  solutions  for  each  ship  type  and 
class  (CVN,  LX,  DD)  may  now  be  unaffordable.  Further,  modernization  is  difficult:  the 
ability  to  add  or  change  interfaces  eventually  becomes  a  bottleneck  to  change  and 
upgrade.  Recently  the  House  Appropriations  Committee^®  identified  the  Navy  as  the 
slowest  of  the  services  to  recognize  the  opportunities  available  from  the  ongoing 
revolution  of  computer  and  software  technology.  It  was  asserted  that  many 
opportunities  to  reduce  costs  and  to  improve  the  effectiveness  of  Navy  operations  are 
missed  through  ineffective  application  of  computer  technology. 


TRENDS  IN  WARSHIP  DEVELOPMENT 

A  quick  review  of  important  trends  will  indicate  why  lack  of  clear  incentives  for 
warship  R&D  is  a  problem.  Major  trends  include  formulation  of  new  concepts  for 
achieving  modularity  in  warships  and  Fleets  and  extending  the  concept  of  survivability 
to  include  signature  reduction. 
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Achieving  Modularity 

The  idea  of  a  ship  built  for  modularity  was  studied  by  NAVSEA  during  the  1970s, 
in  the  SEAMOD  Project,®  and  physically  realized  by  the  MEKO  line  of  warships  in  the 
1980s.  Generally  speaking,  ship  and  combat  system  design  processes  are  closely 
coupled  in  traditional  designs.  Physical  characteristics  and  interface  requirements  of 
combat  system  components  must  be  relatively  well  defined  before  the  ship  design 
phase  begins,  and  the  resulting  design  accommodates  only  the  specified  combat  suite. 
The  problem  is  to  make  the  interfaces  between  ship  and  combat  system  elements 
predictable.  The  use  of  standard  interfaces  was  seen  as  a  possible  solution. 

Decoupling  ship  and  combat  system  design  processes  could  permit  concurrent  design 
efforts  and  make  upgrades  easier.  This  led  to  the  idea  of  a  variable  payload  ship.®  The 
difficulty  of  an  evolutionary  approach  to  implementation  may  be  the  biggest  drawback  of 
this  concept.  Application  of  the  basic  idea  to  selected  modules  such  as  the  Mk  41 
Vertical  Launching  System  (VLS),  however,  has  enjoyed  considerable  success.  Today 
the  Affordability  Through  Commonality  program^®  has  been  established  to  develop 
modular  designs  for  selected  components.  Standards  will  be  defined  for  module  size, 
weight,  center  of  gravity,  environmental  testing,  interfaces,  and  the  like  in  order  to 
optimize  commonality  and  reduce  logistic  support  costs.  Many  of  the  modules  being 
considered  are  ship  systems  rather  than  combat  systems. 

Since  existing  aircraft  carriers  can  be  viewed  as  variable  payload  ships, 
modularity  can  also  be  sought  by  building  the  warfighting  capabilities  into  embarked 
vehicles  (or  mission  teams).  The  basic  idea  involves  the  use  of  a  large  ship  to  reach 
the  operating  area  and  smaller  vehicles  to  deliver  ordnance.  In  effect  this  gives  a  two- 
stage  warfighting  system.  The  embarked  vehicles  need  not  be  fixed  wing  aircraft: 
surface  vessels,  helicopters,  and  unmanned  vehicles  can  be  employed.  Heavy  lift  ships 
such  as  SS  MIGHTY  SERVANT  have  been  used  to  carry  warships  and  could  easily  be 
used  to  deliver  mine  countermeasures  or  special  warfare  craft  to  fonward  operating 
areas.  However,  aircraft  receive  the  most  attention.  Today  it  is  widely  acknowledged 
that  embarked  air  assets  are  essential  for  a  balanced  multiwarfare  combatant.  The 
success  of  LAMPS  motivates  greater  use  of  helicopters.  Unmanned  air  vehicles  may 
find  use  in  minefield  reconnaissance,  general  surveillance,  and  battle  damage 
assessment  roles.  These  trends  raise  new  design  issues  with  respect  to  tasking 
authority,  time  to  change  mission  modules,  and  allocation  of  resources  for  joint  and 
expeditionary  warfare  operations.  The  concept  of  mobile  sea  bases  envisioned  in 
Reference  21  combines  both  approaches  to  modularity. 

Survivability 

Warship  survivability  depends  on  a  total  ship  approach.  Firepower  and  stealth 
influence  survivability  by  reducing  the  probability  of  a  hit.  Many  systems  influence  a 
ship’s  capability  to  survive  a  hit  and  fight  hurt.  Hits  result  in  complex  damage  effects 
that  must  be  rapidly  diagnosed,  prioritized,  and  then  repaired.  Critical  spaces  are 
subject  to  damage  from  fire  or  flooding;  power  and  propulsion  systems  may  be  out  of 
commission  and  fire  mains  cut;  weapons  may  be  damaged  and  people  injured  or  killed. 
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Automated  damage  control  coordination  is  needed  to  gather  status  data,  interpret  it, 
and  determine  priorities  for  repair  action.  The  key  may  be  to  design  for  early  integration 
of  critical  systems  on  a  total  ship  basis,  using  a  survivable  interconnection  network  for 
data,  voice,  imagery,  video,  power,  and  control  of  signal  distribution. 

Current  interest  in  signature  reduction  has  major  implications  for  ship  design 
strategies.  Signature  reduction  involves  a  new  set  of  parameters  linking  ship  systems 
directly  to  warfighting  effectiveness.  Embarked  helicopters  or  unmanned  aerial  vehicles 
(UAVs),  towed  bodies,  and  replenishment  operations  all  make  demands  on  topside 
access  and  can  create  windows  of  vulnerability  by  energy  release  as  well  as  reflection 
of  incident  signal  energy.  The  continuing  competition  for  topside  space  is  also 
exacerbated  by  the  shifting  character  of  design  trades.  For  example,  consider  the 
trades  between  hard  kill,  soft  kill,  and  ship  signature.  Ways  to  achieve  a  given  level  of 
improvement  in  self-defense  capability  include  hotter  missiles,  improved  electronic 
countermeasures,  and  reduced  signature.  Each,  however,  has  different  implications  for 
sensor  design  and  allocation  of  topside  space.  In  addition,  any  shift  away  from  active 
defense  capabilities  tends  to  raise  force  structure  issues. 


FINDING  A  PRACTICAL  APPROACH 

Each  of  these  concepts  involves  different  ways  of  arriving  at  a  ship's  general 
physical  arrangement  and  breakdown  into  modules  for  construction.  Each  demands  an 
approach  to  design  that  cuts  across  the  traditional  breakdown  into  combat  and  ship 
systems.  The  difficulty  is  that  no  one  individual  can  deal  adequately  with  complex 
systems  across  all  relevant  levels  of  concern.  Even  the  Manhattan  project,  the 
Tennessee  Valley  Authority,  and  the  system  of  mass  production  invented  by  Henry 
Ford  had  limits.  Many  attempts  to  design  and  integrate  megasystems,  wrapping 
multiple  requirements  into  one  solution,  have  run  into  severe  technical  and 
organizational  problems.  Accordingly,  many  believe  that  a  modular  or  building  block 
approach  is  the  only  intelligent  way  to  build  large,  integrated  systems.  The  "humpty- 
dumpty"  phenomenon  makes  the  engineering  of  such  systems  difficult.  It  is  all  too  easy 
to  break  a  problem  into  lots  of  little  pieces.  But  if  the  partitioning  approach  is  not 
carefully  chosen,  all  the  king's  horses  and  all  the  king's  men  will  not  be  able  to  weave 
the  pieces  into  the  coherent  warfighting  system  necessary  for  effective  naval 
operations.  For  successful  integration,  each  module  added  to  the  system  must  interact 
smoothly  with  modules  already  in  place.  Articulating  a  practical  approach  to  total  ship 
system  engineering  is  thus  a  key  step  toward  equipping  the  Navy  of  the  future  with 
modern,  affordable,  and  effective  surface  ships.  The  best  practices  of  aircraft, 
construction,  and  other  industries  should  be  reflected  in  the  chosen  approach, 
consistent  with  the  practical  lessons  learned  from  many  decades  of  naval  operations. 
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CHAPTER  2 

SYSTEM  ENGINEERING  ON  A  TOTAL  SHIP  BASIS 


SYSTEM  ENGINEERING  BASICS 

A  system  is  a  set  of  components  interacting  in  some  organized  way  to  achieve  a 
common  purpose.  At  the  core  of  every  system  is  a  control  process  that  governs  how 
inputs  are  transformed  into  outputs.  System  engineering  is  a  robust  approach  to  the 
design,  creation,  and  operation  of  complex  systems.  In  essence,  it  serves  as  a 
transmitter  for  innovation,  intended  to  meet  two  critical  needs.  First,  new  ideas  (signals 
from  some  master  source)  are  modulated  and  amplified  into  programs  matched  to  the 
practical  needs  of  some  large  operating  system  (or  market).  Second,  the  needs  of  the 
operating  system  are  coupled  to  the  process  of  technical  innovation,  transmitting  a 
sense  of  purpose  and  discipline  that  are  critically  important  for  effective  management  of 
engineering  effort.  System  engineering  encompasses  efforts  to  identify  and  quantify 
system  goals,  create  alternative  system  design  concepts,  perform  trade  studies,  select 
and  implement  the  best  design,  verify  that  the  design  is  actually  built  and  properly 
integrated,  and  then  to  assess  how  well  the  system  goals  are  met.  As  part  of  its  role  in 
verification,  system  engineering  controls  the  technical  baselines  of  the  system  (typically 
including  functional,  design-to,  build-to,  as-built,  and  as-deployed  baselines)  and  must 
ensure  an  efficient  and  logical  progression  through  these  baselines.  System 
decomposition  and  design  are  then  pursued  through  the  creation  of  design-to 
specifications  for  all  major  end  items.  Design  engineering  activities  follow  with 
development  of  detailed  engineering  designs  which  comply  with  the  approved  design-to 
baseline.  System  engineering  also  audits  design  solutions  for  compliance  to  the 
higher-level  baselines. 

There  are  five  core  activities  in  system  engineering:  requirements  definition, 
functional  analysis,  synthesis,  evaluation,  and  description  of  product  elements.  The 
flow  of  work  is  iterative,  with  successively  finer  resolution  of  system  design  definition  on 
each  pass.  Overall,  there  are  two  stages,  as  shown  in  Figure  2:  first,  definition  and 
decomposition;  second,  integration  and  verification.  The  aim  of  work  in  the  first  stage  is 
to  select  a  preferred  design  approach.  System  requirements  are  progressively 
decomposed  into  baselines  for  subsystems,  elements,  components,  and  assemblies 
until  the  lowest  level  of  resources  (hardware  parts  or  software  units)  is  specified.  The 
core  problem  is  not  simply  to  divide  and  conquer;  decomposition  must  be  guided  by  a 
strategy  for  integrating  the  subsystems  into  an  overall  solution.  The  challenge  is  to 
decompose  tasks  and  to  allocate  subtasks  without  compromising  the  wholeness  of  the 
task.  When  viewed  from  this  perspective,  it  becomes  clear  that  theories  and  analysis 
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FIGURE  2.  FLOW  OF  WORK  IN  SYSTEM  ENGINEERING 


tools  are  needed  for  representing  the  problem  both  as  a  whole  and  as  a  set  of 
interdependent  subproblems. 

Once  a  preferred  design  approach  is  chosen,  it  is  tested  in  the  second  stage  by 
reversing  (unwinding)  the  decomposition  to  verify  that  system  expectations  and 
requirements  are  met.  However,  activities  of  the  two  sequences  are  in  close 
correspondence:  verification  methods,  for  example,  determined  as  system 
requirements  are  decomposed  and  documented  at  each  level  of  resolution.  Prototyping 
and  engineering  experiments  offer  considerable  scope  for  working  the  two  sequences 
in  parallel  at  a  given  level  of  resolution,  in  order  to  generate  information  needed  for 
development.  When  applied  to  system  architecture  definition,  integration  and 
verification  activity  may  be  called  system  conceptual  integration  and  occurs  in  all 
phases  of  the  acquisition  cycle.  System  physical  integration,  in  contrast,  occurs 
primarily  in  the  late  stages  of  construction  as  production  items  are  delivered  and 
installed.  The  delivered  hardware  parts  and  software  units  are  formed  into  higher  and 
higher  levels  of  assembly  until  a  complete,  functioning  system  is  achieved.  With  the 
exception  of  lead  ship  production  efforts,  the  aim  here  is  not  to  generate  information 
needed  to  specify  or  verify  a  design  but  rather  to  assemble  a  system  from  previously 
verified  component  designs. 
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ARTICULATING  A  NEW  PROCESS 

The  next  step  is  to  articulate  how  system  engineering  may  be  applied  to  surface 
combatants  on  a  total  ship  basis.  A  suitable  process  must  integrate  ship  design, 
construction,  and  support  activities  over  the  entire  value  stream.  This  makes  total  ship 
system  engineering  as  much  a  process  control  or  coordination  problem  as  it  is  a 
technical  problem.  By  eliminating  unnecessary  steps,  aligning  all  steps  in  a  continuous 
flow,  recombining  labor  into  cross-functional  teams,  and  continually  striving  for 
improvement,  more  capable  and  affordable  ships  can  be  produced.  Ships  can  also  be 
made  more  flexible  and  responsive  to  user  needs. 

But  this  is  not  the  end  of  the  road  to  improvement.  Many  activities  add  value  to 
surface  ships,  and  their  net  value  to  the  nation's  defense  can  be  raised  dramatically  if 
individual  breakthroughs  can  be  linked  up  and  down  the  value  chain.  Maximum  net 
value  can  be  achieved  only  if  the  activities  involved  can  work  together  as  a  team.  The 
chief  concern  in  process  design  is  to  ensure  that  all  major  design  decisions  are  based 
on  what's  best  for  the  ship  as  a  whole,  rather  than  what's  best  for  any  particular 
component  system  or  class  of  systems.  For  this,  three  things  are  necessary: 

•  A  culture  of  teamwork  permitting  a  unified  system  engineering  effort 

•  A  common  framework  for  total  ship  system  engineering 

•  Agreed-to  concepts,  standards,  and  tools  for  design  integration 

The  root  concern  is  to  ensure  that  future  naval  forces  are  capable  of  executing  a 
chosen  concept  of  operations  against  a  capable  and  determined  adversary. 


CULTURE  OF  TEAMWORK 

Achieving  cooperation  within  the  value  stream  is  difficult  because  the  component 
activities  have  needs  that  conflict  with  those  of  the  value  stream.  Every  stream  needs  a 
team  leader  that  orchestrates  the  decision  to  form  an  enterprise,  pulls  together  the  full 
complement  of  members,  and  leads  the  joint  analysis  of  the  total  enterprise  stream. 
Unfortunately,  this  leadership  position  is  easily  used  to  extract  advantage  from  upstream 
and  downstream  partners.  If  component  activities  are  to  work  together  effectively,  a  culture 
of  teamwork  must  be  established.  Formation  of  a  system  engineering  cadre  able  to 
consider  tradeoffs  from  a  total  ship  point  of  view  may  be  the  most  crucial  factor  in 
establishing  such  a  disciplined  management  approach.  A  possible  strategy  for  cadre 
formation  might  proceed  as  follows: 

•  Create  a  top-level,  process  definition  team 

•  Form  a  technical  cadre,  trained  to  a  common  framework  and  lexicon 
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•  Organize  this  cadre  into  a  small  number  of  teams,  each  to  address 
integrated  design  concepts,  standards,  and  tools  for  a  selected  core 
subsystem. 


Partitioning  the  overall  control  problem  into  a  small  number  of  backbone  areas  (or 
core  subsystems)  is  a  critical  step  in  establishing  a  culture  of  teamwork.  A  decision  must 
be  made  very  early  in  the  system  definition  process,  and  it  is  all  too  easy  to  find 
convenient  pieces  without  establishing  clearly  how  they  will  work  together  to  form  a  well- 
integrated  operating  entity.  It  is  critical  at  this  point  to  provide  a  framework  for  defining 
and  controlling  how  the  corresponding  teams  can  achieve  a  unity  of  effort  in  system 
engineering.  A  basic  control  structure,  provision  for  resource  sharing  among  subsystems, 
and  a  workable  approach  to  change  and  upgrade  actions  must  all  be  articulated  at  this 
point.  Adequacy  of  the  engineering  process  depends  on  what  it  takes  to  make  these 
decisions.  Proposals  for  a  virtual  enterprise,  in  which  contributors  come  and  go  (plug  and 
play  fashion),  fail  to  grasp  the  massive  costs  of  the  casual  interactions  involved.  Such 
arrangements  may  work  for  emerging  industries  in  which  product  specification  and  market 
demand  are  subject  to  dramatic  and  unpredictable  change,  but  they  are  terrible  for  the 
vast  majority  of  activities. 

Hostile  relationships  among  the  component  activities  cannot  be  ended  simply  by 
trust.  Practical  arrangements  must  be  rooted  in  agreed  principles  of  just  behavior  and 
procedures  that  enable  each  party  to  verify  that  others  are  keeping  their  end  of  the  deal. 
The  component  activities  in  a  stream  must  discuss  the  total  activity,  performance 

requirements  for  individual  activities,  performance  verification  procedures,  and  reward 
formulas. 


COMMON  FRAMEWORK 

For  a  large  composite  system  such  as  a  ship,  dealing  with  component  systems  one 
by  one  is  not  good  enough.  A  better  approach  is  needed,  one  that  permits  coordination  of 
many  independent  projects  to  create  a  fully  integrated  system  of  systems.  Such  an 
approach  is  considered  in  References  22  through  27.  The  basic  idea  is  that  total  ship 
system  engineering  involves  a  hierarchy  of  design  levels  and  that  systems  at  any  one 
level  are  embedded  in  successively  higher  level  systems  that  address  discrete  operating 
tasks,  individual  mission  areas,  ship  characteristics,  and  ultimately  national  systems  that 
transcend  even  the  specific  military  purpose  of  DoD.  For  example,  a  radar  might  be 
considered  a  component  of  an  air  defense  system,  air  defense  part  of  the  nation's  defense 
system,  which  in  turn  is  part  of  the  Joint  Chiefs  of  Staff-managed  military  system.  That 

system  then  must  operate  within  a  national  system  that  includes  others  such  as  the  air 
traffic  control  system. 

A  system  of  systems  is  one  that  is  formed  by  integrating  other  systems,  each  a 
product  in  its  own  right  and  with  its  own  development  sites,  objectives,  management,  and 
schedule.  In  many  cases,  component  systems  are  taken  off  the  shelf  and  integration  must 
proceed  in  a  bottom-up  manner.  Since  complete  systems,  rather  than  subsystems  or 
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modules,  must  be  integrated,  system  integration  is  more  difficult  than  usual.  Not  only  are 
the  components  to  be  integrated  more  complex,  but  each  may  have  its  own  standards, 
and  it  can  be  difficult  to  understand  behavior  of  the  overall  system.  The  overall  system 
may  be  general  purpose  or  specialized.  The  flight  control  system  for  a  jumbo  jet  is  an 
example  of  the  latter  type,  which  may  be  large  and  complex  but  is  intended  to  solve  a 
particular  problem  in  a  given  time  frame.  Surface  ships  are  an  example  of  the  former  type, 
which  operate  in  a  given  application  domain  but  are  multipurpose  and  must  be  flexible  as 
to  the  time,  place,  and  circumstances  of  use.  While  the  same  idea  is  present  in  the 
proverb  relating  loss  of  a  kingdom  to  loss  of  a  horse  shoe  nail,  first  use  of  this  term  may  be 
due  to  John  Jacobs.^® 

Since  development  of  a  system  of  systems  usually  involves  people  working  at 
multiple  sites,  with  different  management  teams  and  procedures,  communication  problems 
are  likely  to  occur.  To  solve  the  communication  problems,  much  more  emphasis  on 
definition  of  interfaces  and  specifications  is  required.  However,  considering  specification 
of  interfaces  only  does  not  ensure  that  required  operations  are  done  in  the  required  order 
and  manner.  Required  behavior  must  be  specified  as  with  traditional  systems,  but  now 
the  problem  is  even  more  complicated.  Required  behavior  must  be  specified  not  only  for 
component  systems,  but  also  for  the  overall  system. 

Because  of  the  dynamics  and  the  relatively  long  time  frame  involved  in  this  kind  of 
development,  requirements  analysis  cannot  be  done  as  a  specific  step  at  the  beginning  of 
the  development  process.  New  methods  and  processes  must  be  defined  to  cope  with  the 
specific  problems  of  this  category  of  systems.  Use  of  a  generic  framework,  dividing  the 
overall  effort  into  several  projects  and  two  levels  of  management,  is  suggested.  Figure  3 
shows  such  a  framework.  One  level  provides  coordination  for  the  overall  system,  working 
across  projects,  while  the  other  manages  individual  projects.  Establishment  of  this 
framework  begins  with  domain  analysis,  to  establish  a  basis  for  specifying  requirements. 
Infrastructure  and  integration  architecture  are  used  to  enable  integration  of  component 
systems  into  a  consistent  overall  system  in  an  efficient  way. 
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FIGURE  3.  SYSTEMS  OF  SYSTEMS  ENGINEERING  FRAMEWORK 
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MECHANISMS  FOR  DESIGN  INTEGRATION 

Design  integration  involves  all  engineering  necessary  to  fully  integrate  the 
component  systems.  Key  responsibilities  include  defining  system  top-level  functional 
capabilities,  assuring  intersystem  performance,  and  verifying  that  there  is  an  integrated 
architecture  in  distinction  to  a  random  collection  of  subsystems  that  have  somehow  been 
put  together  and  barely  interoperate.  Indeed,  the  purpose  of  this  activity  is  to  optimize 
overall  system  performance,  despite  the  fact  that  component  systems  were  developed 
under  quite  different  conditions  and  ground  rules.  It  is  the  single  point  at  which  overall 
system  integrity  is  examined  in  order  to  maintain  or  improve  performance.  Software  has 
been  and  likely  will  continue  to  be  the  most  difficult  and  high  risk  aspect  in  acquisition  of 
large-scale  systems.  Configuration  management  is  also  a  significant  problem  in  that  the 
different  schemes  under  which  individual  systems  were  developed  must  be  integrated  to 
the  maximum  extent  possible.  This  is  necessary  to  provide  in-service  support  for  the 
overall  system. 

System  of  systems  engineering  involves  two  kinds  of  integration,  one  that  focuses 
on  mechanisms  used  to  interconnect  parts  and  another  that  focuses  on  the  uniformity  of 
an  overall  system  design.  A  dictionary  definition  of  the  term  integration,  "make  whole  or 
complete  by  bringing  together  parts,"  succinctly  captures  this  tension  between  the  parts 
and  the  whole.  On  the  one  hand,  we  talk  about  a  system,  a  whole  or  complete  thing;  on 
the  other,  we  talk  about  bringing  together  parts.  The  system  side  of  the  equation 
emphasizes  global  system  properties;  e.g.,  the  harmonious  "look  and  feel"  of  user 
interfaces,  or  the  linguistic  elegance  of  system  structure.  The  parts  side  of  the  equation 
emphasizes  interconnection  and  interoperation;  e.g.,  interoperability  of  functions,  data 
files,  and  subsystems. 

These  two  kinds  of  integration  reflect  different  development  processes.  When  a 
system  is  designed  before  its  components  are  designed  and  built,  we  speak  of  pre-facto 
integration.  If  the  parts  are  designed  and  built  before  the  system  is  designed,  or  even 
conceived  of,  we  speak  of  post-facto  integration. 

The  two  types  of  integration  come  together  in  the  phased,  top-down  approach 
discussed  in  References  22  and  25.  Large  and  complex  systems  tend  to  make  system 
development  and  integration  a  highly  complex  process,  requiring  flexible  but  firm 
management  that  takes  future  changes  in  requirements  and  technology  into  consideration 
from  the  beginning.  Requirements  of  large  and  complex  systems  are  inherently 
incomplete  and  have  a  tendency  to  change.  Requirements  are  seen  only  as  a  starting 
point,  subject  to  change  on  agreement  by  the  user  and  developer,  and  this  makes  system 
integration  even  more  complex.  Typical  acquisition  processes  demand  quick  decisions, 
influencing  the  future  integration  structure  in  unpredictable  ways  and  leading  to  design 
errors  that  are  hard  to  correct.  To  overcome  these  difficulties,  system  development  and 
integration  is  divided  into  two  phases,  archetyping  and  actual  system  building.  The  two 
phases  are  independent  and  archetyping  is  the  topic  of  interest  here.  It  is  split  into  two 
steps,  architecting  and  prototyping. 
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Architecting  uses  a  top-level  design  approach  to  construct  a  model  of  the  system. 
Such  a  generic  model  (integration  architecture)  allov^s  integration  of  already  existing 
components  and  provides  a  framework  for  interface  definition,  performance  assessment, 
and  cost  evaluation.  However,  the  model  should  be  generic  and  robust  enough  to  provide 
flexibility  and  adaptivity  for  changes  in  requirements  and  technologies.  Sensitivity  analysis 
and  simulation  are  suggested  for  use  in  this  stage  to  obtain  reliable  results. 

The  prototyping  step  of  the  archetyping  phase  is  used  to  construct  an  architected 
and  tested  demonstration  prototype  of  the  system.  This  prototype  is  then  used  to  verify 
the  architecture  and  to  check  the  assumptions  made  in  the  architecting  step.  Actual 
system  building,  following  archetyping,  is  a  relatively  conventional  phase,  based  on  the 
principles  of  system  engineering.  Besides  the  technical  part,  it  includes  monitoring  of 
progress,  user  training,  and  verifying  assumptions  (e.g.,  about  system  performance)  made 
in  the  archetyping  phase.  This  phase  always  follows  archetyping  and  can  be  performed 
either  by  in-house  development  of  the  integrated  system  or  by  an  external  contractor.  In 
both  cases,  developers  have  to  work  according  to  the  results  of  the  preceding  archetyping 
phase.  This  phased,  top-down  approach  includes  the  three  dimensions  of  enabling 
technologies,  integration  architecture,  and  global  integration.  In  its  architecting  step,  it 
defines  an  integration  architecture  and  addresses  global  integration  issues  without  binding 
the  system  too  early  to  existing  solutions  and  technologies.  This  makes  the  architecting 
phase  a  critical  step  that  has  to  be  supported  properly  by  methods,  reference 
architectures,  standards,  and  tools. 

Role  of  Integration  Architecture 

Integration  architecture  is  the  core  of  this  framework.  Architecture  is  a  logical 
construct  for  defining  and  controlling  the  system  engineering  process.  Its  definition  begins 
with  a  structure  (partitioning)  and  control  strategy  enabling  all  parts  of  the  system  to  work 
smoothly  together  in  performing  mission  tasks.  In  particular,  the  architecture  concept 
should  include  an  extension  framework  and  be  subject  to  formal  change  control  from  the 
earliest  stages  of  development.  What  is  common  to  all  types  of  integration  architectures  is 
a  decomposition  into  two  main  parts,  the  conceptual  model  and  the  technical 
infrastructure.  The  first  links  the  domain  analysis  to  the  infrastructure  created  to  support 
development.  The  second  provides  the  standardized  services  necessary  to  ensure  that  all 
projects  in  the  domain  can  rely  on  a  standard  implementation  platform.  These  services 
must  be  developed  and  maintained  as  part  of  a  separate  project  above  the  level  of 
individual  system  efforts.  This  provides  the  support  environment  for  implementing  an 
individual  system  following  the  rules  of  the  conceptual  model.  Once  specified,  the 
integration  architecture  becomes  the  basis  for  all  other  decision  processes  regarding 
system  development  in  the  domain  of  interest. 

The  concept  of  integration  architectures  refers  to  the  idea  that  an  integrated  system 
should  have  a  strategically  chosen  open  architecture,  implemented  on  the  basis  of 
identified  enabling  technologies.  An  integration  architecture,  like  a  system  specification  for 
an  individual  project,  serves  as  a  general  pattern  or  blueprint  for  defining  the  basic  layout 
of  an  integrated  system.  Grounded  in  domain  analysis,  it  must  indicate  how  all  parts  of 
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the  overall  system  can  work  smoothly  together  to  accomplish  mission  tasks.  In  particular, 
it  provides  a  general  strategy  for  system  decomposition,  data  storage,  interprocess  and 
user  communications,  and  the  handling  of  internal  and  external  interfaces.  Changes 
should  be  placed  under  control  from  the  first  stages  of  development,  and  an  extension 
framework  identified.  Further,  guidelines  (principles  or  metarules  for  system  design)  and 
standards  should  be  provided  for  the  design  of  individual  systems  and  the  bottom-up 
integration  of  partial  solutions  that  already  exist.  From  a  global  view  of  the  domain,  the 
integration  architecture  functions  like  a  strategic  planning  scheme  for  the  overall 
organization  by  (a)  pointing  out  key  directions  and  tradeoffs  for  design,  (b)  ensuring  that 
individual  projects  contribute  to  goals  of  the  overall  system,  and  (c)  ensuring  compatibility 
and  communication  among  all  ongoing  efforts.  Once  specified,  it  becomes  the  basis  for  all 
other  decision  processes  regarding  system  development  in  the  domain. 

Hardware  architectures  fill  the  job  of  a  generic  and  standardized  blueprint  for 
different  models  of  one  machine  architecture.  As  with  hardware  architectures,  integration 
architectures  serve  as  generic  blueprints  for  the  management  of  complex  systems.  They 
deal  on  the  one  hand  with  standards,  guidelines,  and  domain  knowledge  on  a  conceptual 
level  and  on  the  other  hand  with  the  necessary  environmental  infrastructure  like  hardware, 
networking,  operating  systems,  and  protocols.  However,  working  within  an  integration 
architecture  means  to  work  within  boundaries.  These  boundaries  will  reduce  the  freedom 
of  choice  we  have  and  will  support  some  types  of  application  while  complicating  the 
implementation  of  others. 

Integration  architectures  have  a  natural  place  in  between  conceptual  domain 
knowledge  and  implementation-oriented  enabling  technologies,  which  makes  them  a 
useful  basis  for  decision  processes.  Domain  analysis  delivers  a  general  specification  for 
the  architecture's  functionality  and  data  handling  capabilities,  while  the  infrastructure  level 
offers  a  set  of  technologies  that  enable  implementation  of  the  architecture  and  embedded 
applications.  A  core  set  of  tools  and  technologies  forms  the  designated  basis  for  the 
architecture  and  so  merits  a  high  priority  in  support  and  development.  On  top  of  the  core 
technologies,  development  and  run  time  environments  are  defined  and  maintained.  The 
core  set  must  be  limited  in  extent,  yet  sufficient  to  support  the  full  architecture.  This 
simplifies  relationships  between  the  integration  architecture  and  its  enabling  technologies. 
At  the  same  time,  the  core  must  be  reexamined  on  a  regular  basis,  permitting  cycles  of 
adaptation  and  change  to  rejuvenate  the  architecture. 

Elements  of  an  Integration  Architecture 

Conceptual  Layout.  With  regard  to  conceptual  layout,  an  integration  architecture  does  not 
ask  for  a  specific  form  of  implementation.  An  architecture  with  a  common  database  as  a 
basis  for  communication  and  data  storage  might  be  implemented  on  top  of  a  distributed 
database  management  system  (DBMS)  whose  characteristics  are  hidden  from  the 
architectural  level  of  specification.  The  DBMS  is  used  transparently.  To  guide  this  kind  of 
implementation  effort  and  to  ensure  compatibility  between  implementors,  standards  and 
guidelines  for  implementation  must  be  defined. 
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Domain  Model.  Global  integration  focuses  on  the  integrated  system  as  a  whole  and  not 
on  the  parts  of  the  system.  To  prevent  use  of  highly  complex  and  incompatible  data 
structures  in  different  parts  of  the  system,  to  preserve  a  common  universe  of  discourse  for 
users  and  processes,  and  to  allow  easy  integration  of  new  applications,  a  domain  model 
must  be  defined.  Based  on  a  common  universe  of  discourse,  a  generalized  process 
model  of  the  domain  can  be  specified  to  reflect  the  common  understanding  of  tasks,  roles, 
and  resources  and  to  reflect  the  knowledge  and  standards  for  data  processing  in  the 
chosen  domain.  This  process  model  is  used  as  a  reference  model  on  the  meta  level  to 
coordinate  integration  activities. 

Considering  the  immature  nature  of  the  total  ship  system  engineering  field,  the  first 
task  of  a  process  engineer  is  to  design  a  process  and  its  support  elements  before  tool 
support  and  distinct  applications  are  considered.  Constructing  a  process  model  assures 
a  common  understanding  of  the  application  domain  and  the  feasibility  of  developing  a 
conceptual  architecture.  As  soon  as  a  process  is  defined  and  implemented  in  a 
supporting  (tool)  environment,  the  product  engineer  can  handle  the  development  of 
applications  in  an  integrated  manner. 

The  National  Institute  of  Standards  and  Technology  (NIST)  Application  Portability 
Profile  model  (see  Reference  29)  appears  to  be  an  instance  of  the  approach  outlined 
above.  It  is  based  on  a  concept  of  computing  and  a  mapping  of  this  concept  into 
component  and  service  categories.  This  involves  an  integrated  view  of  how  information  is 
organized  and  used  in  development  and  application  of  computing  resources  and  the 
specification  of  a  generalized  process  model  for  computing  operations.  Domain  analysis 
is  a  necessary  first  step  in  this  approach.  Any  global  definitions  and  standards  applicable 
to  the  framework,  perhaps  based  on  prior  steps  toward  global  integration,  must  be 
considered  as  an  influence  on  the  architecture  design. 

Decomposition  Strategy.  The  decomposition  strategy  provides  a  common  pattern  of 
thinking,  describing  what  global  system  functions  will  be  addressed  by  each  newly 
developed  system  component.  These  global  functions  are  identified  from  analysis  of  the 
application  domain  and  the  structure  of  the  chosen  conceptual  integration  architecture. 

Architecture  Standards.  How  functions  are  implemented  is  not  of  interest  for  the 
architecture.  Essential  capabilities  are  identified  without  specifying  how  they  will  be 
implemented.  Two  major  issues  in  defining  the  technical  aspects  of  integration 
architectures  are  the  description  of  communication  and  data  handling  within  the  system. 
Standardized  messages  and  a  common  global  database  can  help  to  reduce  the 
complexity  of  communication  and  data  transfer.  The  specification  of  communication  in  an 
integrated  system  and  the  handling  of  data  in  the  system  are  closely  related.  Systems 
that  rely  on  communication  via  a  common  database  are  naturally  implemented  with  a 
standardized  central  repository.  Systems  with  distributed  data  handling  involve  an 
elaborated  message  passing  concept  and  rely  heavily  on  predefined  and  secured 
communication  channels  between  components. 
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Guidelines  for  Implementation.  Whereas  a  domain  reference  model  defines  the  meta  level 
of  the  integration  architecture,  implementation  guidelines  define  a  basis  for  the 
architecture  in  terms  of  existing  methods  and  tools.  Enabling  technologies  are  the  tool 
level  of  the  framework  (Figure  3)  and  provide  elements  required  by  the  infrastructure  to 
develop  and  implement  individual  systems  that  will  fill  the  abstract  architecture  with 
functionality  and  data.  Backbone  activities  should  not  only  be  concerned  with  the  state  of 
the  art  in  technology  but  also  give  suggestions  for  standards  and  developments  in  the 
domain.  The  standards  used  for  implementation  describe  the  technological  basis  on 
which  the  generic  integration  architecture  is  implemented.  A  typical  example  is  the 
specification  of  the  Open  Systems  Interconnection  (OSI)  model  as  a  basis  for  all 
communication  in  the  architecture  and  for  the  selection  of  specific  services  to  implement 
them.  The  standards  for  communication  are  specified  on  top  of  the  application  layer  of  the 
International  Standards  Organization  (ISO)/OSI  model.  The  implementation  guidelines 
also  specify  hardware  restrictions,  programming  languages,  coding  standards, 
documentation  guidelines,  and  the  like. 

Types  of  Integration  Architectnrp 

Three  types  of  integration  architecture  are  found  in  many  existing  large-scale 
systems:  (a)  message  passing,  (b)  systems  with  a  central  data  repository,  and  (c)  generic 
systems.  In  its  basic  layout,  the  message-passing  approach  is  a  variation  of  the  object- 
oriented  and  channel-based  schemes  that  are  widely  used  in  hardware  systems.  Both 
schemes  provide  sufficient  flexibility,  adaptability,  and  scalability  for  use  in  a  wide  range  of 
application  domains.  Channel-based  systems  represent  a  form  of  object-oriented  system, 
while  systems  with  a  central  data  repository  can  be  viewed  as  a  form  of  generic  system. 
These  three  architecture  concepts  thus  represent  a  unifying  framework  for  integration  of 
individual  systems  and  for  describing  the  types  of  individual  systems  that  may  be 
contained  within  a  ship.  By  studying  the  concepts,  their  use  in  different  application 
domains  and  their  influence  on  enabling  technologies,  practical  rules  and  tradeoffs  can  be 
identified  and  used  as  guidelines  for  total  ship  system  engineering.  Concurrent  systems 
with  message  passing  between  processes  and  objects  and  systems  linked  by  a  common 
data  repository  are  widely  used  for  integration  of  multiple  application  systems. 

Furthermore,  they  provide  approaches  that  can  be  used  to  create  highly  flexible,  generic 
systems  specifications. 

An  open  system  approach  is  needed  for  successful  application  of  any  kind  of 
integration  architecture.  Specification,  design,  and  eventually  implementation  details 
should  not  be  proprietary  information,  but  should  be  available  for  every  interested  user  or 
vendor.  An  open  system  would  have  to  define  at  least  the  following  system  parts  and 
ideally  give  some  freedom  to  modify  them:  basic  architecture,  user  interface,  data  storage 
and  representation,  system  functions,  data  transfer,  and  the  enabling  technologies  used. 

As  an  example.  Reference  30  indicates  how  this  can  be  done.  An  open  system  approach 
seems  to  be  feasible  in  terms  of  technical  risk,  user  satisfaction  and  affordability. 

Message  Passing.  In  systems  with  this  architecture,  components  exchange  messages  in 
standard  format  using  a  predefined  communication  system.  The  messages  trigger 
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component  activities.  This  approach  emphasizes  the  communication  side  of  the 
architecture  and  leaves  data  handling  to  the  distributed  components  of  the  system,  which 
act  like  data  capsules.  Message-passing  systems  can  be  used  easily  as  models  for 
integration  architectures  or  as  a  backbone  for  a  targeted  system  in  the  integration  process. 
A  channel-based  approach  goes  naturally  with  a  concept  of  distributed  data  storage.  A 
central  data  repository  can  serve  as  a  component  in  this  architecture,  but  it  may  trigger 
such  problems  as  overloading  of  the  channel  and  performance  bottlenecks  in  the  data 
processing. 

Central  Data  Repository.  Systems  are  designed  with  a  central  data  repository  when  the 
main  resource  that  has  to  be  managed  is  data.  This  occurs  often  in  integrated 
development  environments,  where  a  general  model  for  domain  information  processing  is 
used  instead  of  a  single  application  program.  Special  attention  has  to  be  paid  to  design  of 
a  conceptual  model  for  the  data  and  to  development  of  the  associated  database  system. 

In  pure  form,  this  architecture  links  components  only  through  the  central  database.  Since 
the  database  is  the  main  integrating  factor,  components  usually  can  be  added  or  deleted 
without  severe  direct  side  effects  on  other  parts  of  the  system.  A  good  example  of  this 
type  of  architecture  is  given  by  Best.®^ 

Generic  Systems.  With  integration  becoming  a  major  concern  for  system  acquisition, 
increasing  emphasis  is  being  placed  on  systems  which  are  generic  rather  than 
prepackaged  and  ready  to  use,  but  fixed  in  most  details.  A  generic  system  has  a  range  of 
operating  parameters,  so  that  appropriate  values  can  be  selected  to  tailor  its  operating 
characteristics  for  a  particular  application  environment.  Usually  the  system  is  designed  to 
support  several  different  patterns  of  use,  to  be  implemented  by  choosing  components  from 
a  family  of  items  with  similar  functionality  and  layout.  Methods  of  communicating  between 
components  are  predefined  in  the  application  and  supported  by  integrity  rules  describing 
interfaces  and  parameters.  Strict  consistency  rules  are  necessary  to  ensure  the 
components  fit  within  the  predefined  application  framework.  Designs  must  permit  change 
in  patterns  of  use,  including  addition,  deletion,  or  adaptation  of  functions.  Most  generic 
systems  are  targeted  on  a  well-defined  segment  of  some  application  domain. 

Modeling  and  Simulation 

The  potential  role  of  modeling  and  simulation  in  ship  design,  acquisition,  and 
operation  is  considered  by  Cannon-Bowers^^  and  Jons  et  al.®^  Models  have  been 
employed  for  thousands  of  years  as  an  aid  to  shipbuilding.  Due  to  advances  in  modern 
technology,  computer-based  models  are  commonly  used  for  this  purpose  today.  In  fact, 
unprecedented  opportunities  exist  for  applying  simulation  and  modeling  technology  to  the 
challenge  of  designing,  testing,  and  operating  surface  ships  in  the  21st  century. 

Enormous  leverage  can  be  gained  from  application  of  such  technology  for  idea 
generation,  program  definition,  full-scale  development,  and  production  of  advanced 
systems.  Moreover,  modeling  and  simulation  can  also  mean  major  gains  in  training  and 
operational  flexibility  for  future  surface  ships. 
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Mod6rn  d6sign6rs  are  faced  with  the  daunting  challenge  of  engineering  warfare 
systems  that  do  more  with  less.  Simulation  and  modeling  can  play  any  of  several  roles  in 
formation  of  operating  concepts  and  design  options  for  a  new  ship.  First,  effectiveness  of 
a  particular  design  can  be  estimated  by  simulation-based  analysis  of  its  performance  in 
likely  warfare  scenarios.  Second,  studies  of  cost  and  benefit  factors  can  be  used  to 
assess  the  marginal  costs  associated  with  changes  or  trade-offs  in  planned  capabilities. 
Third,  a  well-developed  simulation  and  modeling  capability  will  allow  for  the  forecasting  of 
requirements  and  costs  associated  with  ship  personnel  and  resource  needs,  operating 
costs,  life  cycle  support,  logistics  concerns,  and  training  needs.  Finally,  the  tactical  roles 
of  a  proposed  combatant  can  be  investigated. 

To  accomplish  these  objectives,  several  technologies  are  applicable.  First,  effort 
devoted  to  developing  the  synthetic  battlefield  and  synthetic  theater  of  war  are  useful 
because  they  bring  together  a  diverse  set  of  models  and  simulations  into  a  coordinated 
testbed.  This  testbed  provides  a  rich  backdrop  in  which  potential  platform  capabilities  and 
roles  can  be  estimated.  In  addition,  the  perfection  of  distributed  interactive  simulation 
(DIS)  technology  provides  for  high-fidelity  testing  of  simulated  platforms  interacting  with 
both  live  participants  and  other  simulated  nodes.  Finally,  virtual  technologies  are  maturing 
to  the  point  where  they  can  be  used  to  assess  initial  human  factors  requirements  for 
various  design  options.  In  this  manner,  users  can  become  involved  in  the  initial  concept 
formation  phase  of  total  ship  system  engineering. 

The  overall  impact  of  the  capabilities  afforded  by  simulation  and  modeling  in  design 
and  testing  is  that  they  foster  an  iterative  or  progressive  testing  strategy.  Through  a 
progression  of  high-fidelity  simulations,  it  is  possible  to  refine  design  options,  assess 
competing  design  strategies,  and  assess  the  logistic  and  life  cycle  costs  associated  with 
particular  designs.  This  includes  stimulating  and  evaluating  various  states  of  platform  or 
situation  degradation.  Further,  since  simulation  offers  the  capability  to  test  the  developing 
system  under  a  variety  of  conditions,  the  limits  of  system  performance  can  be  assessed 
before  development  is  complete.  Likewise,  a  ship's  ultimate  performance  can  be  tested 
more  completely  and  under  more  situational  and  mission  conditions  employing  high-fidelity 
and  distributed  simulations  than  would  be  possible  otherwise.  This  can  allow  system 
users  to  assess  many  end-use  concerns  (e.g.,  safety  or  manning)  early  in  the  design 
process,  thereby  avoiding  costly  mistakes  and  frequent  backfits  once  weapons  are  fielded. 
A  host  of  human  factors  questions  can  also  be  investigated,  including  human-machine 
interfaces,  display  design,  information  flow,  communications  channels,  and  team 
coordination  requirements.  Simulation-based  testing  can,  therefore,  become  a  routine 
part  of  the  design  and  testing  cycle. 
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CHAPTER  3 

ANALYSIS  OF  THE  SURFACE  SHIP  DOMAIN 


Because  the  US  is  a  maritime  nation,  our  forces  must  operate  and  fight 
overseas,  joining  with  allies  and  coalition  partners  to  protect  our  vital  interests.  In 
wartime  operations,  US  naval  forces  must  be  able  to  fight  and  win  against  a  capable 
and  determined  enemy.  In  cases  short  of  war,  US  naval  forces  must  be  able  to  operate 
forward  with  a  view  to  preventing  conflicts  and  controlling  crises.  The  problem 
addressed  in  this  report  is  how  to  create  affordable,  capable,  and  usable  surface  ships, 
sufficient  to  execute  a  chosen  concept  for  employment  of  naval  forces  in  either  wartime 
or  peacetime  operations.  The  starting  point  must  be  a  clear  and  succinct  understanding 
of  why  existing  ships  are  designed  as  they  are  and  what  makes  the  designs  valid. 
Accordingly,  a  functional  reference  model  for  surface  ships  is  formulated  below. 

Creating  such  a  model  and  the  associated  vocabulary  makes  it  easier  to  share  ideas 
and  accumulated  knowledge  throughout  the  Navy  community.  With  such  intellectual 
tools  one  can  proceed  to  dissect  a  maritime  strategy  and  identify  its  implications  for  how 
ships  are  designed  and  built. 


ACCOMPLISHMENT  OF  MISSION  TASKS 

A  warship  is  a  complex  of  people,  plant,  and  procedures  that  together  form  a 
warfighting  system.  The  ship  is  only  an  instrument  wielded  by  the  crew  to  accomplish 
mission  tasks  and  may  be  viewed  as  a  plant  for  the  execution  of  operating  processes 
as  directed  by  mission  teams.  Combatants  accomplish  their  military  purpose  by 
delivering  ordnance  on  target.  Amphibious  ships  are  designed  to  deliver  landing  forces 
for  operations  ashore.  Replenishment  ships  accomplish  their  military  purpose  by 
delivering  ammunition,  fuel,  and  stores  to  the  force.  Each  makes  a  vital  contribution  to 
successful  warfighting  operations,  and  requirements  based  on  military  doctrine  define 
the  operational  tasks  and  capabilities  necessary  to  accomplish  this  purpose.  Each  ship 
type  is  designed  to  support  a  general  concept  of  operations,  with  minimum  dependence 
on  operational  or  implementation  details  that  cannot  be  reliably  foreseen. 

Each  operating  process  involves  a  string  of  discrete  steps  or  functions,  arranged 
to  accomplish  a  significant  mission  task.  Strings  of  these  steps  or  functions  (called 
action  paths)  are  the  counterpart  in  warships  of  the  customer-oriented  transaction  loops 
found  in  commercial  enterprises.  As  an  example.  Figure  4  gives  functions  and  task 
flows  for  a  notional  antiair  warfare  action  path.  Rigorous  definition  of  such  action  paths 


19 


NSWCDD/TR-95/152 


FIGURE  4.  FUNCTIONS  AND  TASK  FLOWS  FOR  AN  ANTIAIR 
WARFIGHTING  ACTION  PATH 


is  a  fundamental  task  in  system  design  and  calls  for  significant  technical  effort.  Here 
the  intent  is  only  to  group  functions  into  sense,  control,  and  act  modules  as  a  simplified 
way  of  describing  action  paths.  All  complex  tasks  involve  sensing,  to  gather  and 
assess  relevant  information;  control,  to  assess  options  and  allocate  resources;  and 
action,  to  alter  the  state  of  the  ship  and  external  entities  or  both  by  expending 
resources.  The  modules  are  viewed  as  functional  rather  than  physical  entities.  For 
example,  sensing  functions  in  antisurface  warfare  action  paths  may  be  supported  by  an 
acoustic  sensor  intended  primarily  for  detecting  and  tracking  submarines. 

With  these  conventions  for  describing  and  arranging  action  paths,  a  process 
model  for  the  surface  ship  domain  can  be  constructed.  Surface  combatants  must 
execute  a  wide  range  of  action  options,  as  suggested  by  Figure  5,  responsive  to  the  will 
and  direction  of  assigned  mission  teams.  Setup,  coordination,  and  control  of  action 
paths  are  the  essential  tasks  of  the  command  and  control  structure,  which  is  designed 
around  the  mix  of  action  paths  which  must  be  executed.  Planning,  training,  maneuver, 
interaction  with  friendly  units,  and  delivery  of  weapons  against  a  target  are  examples. 
While  individual  systems  generate  the  action  paths,  control  structures  create  value  by 
coordinating  many  action  paths.  Coordination  is  necessary,  for  example,  to  avoid 
interference  and  share  resources  across  multiple  action  paths. 

The  domain  reference  model  is  framed  to  capture  basic  missions  and  operating 
concepts  rather  than  specific  details  of  process  implementation.  It  must  provide  for 
definition  of  key  concepts  and  a  structure  accommodating  relationships  between  the 
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FIGURE  5.  ACTION  PATHS  FOR  SURFACE  COMBATANTS 


terms  defined.  For  completeness,  the  relationships  considered  should  cover  all  actions 
expected  in  any  given  operating  environment.  In  addition,  the  reference  model  should 
reflect  planning  concepts  and  doctrines  for  the  conduct  of  naval  warfare,  as  they  relate 
to  the  employment  of  surface  ships. 

Types  of  Operating  Processes  Executed 

It  is  important  to  consider  the  different  types  of  processes  executed.  A  high-level 
description  for  any  process  can  be  formulated  in  terms  of  entities,  interactions,  and 
systems.  A  system  is  defined  as  a  combination  of  human,  computer,  and  network 
elements  that  constitute  operational  capabilities  for  the  ship.  Entities  are  people, 
machines,  or  events.  An  interaction  is  a  sequence  of  events  involving  entities  and 
systems.  Surface  ships  support  two  different  types  of  operating  processes,  each  calling 
for  a  different  approach  to  system  design.  For  many  systems,  functionality  can  be 
described  by  a  simple  relation  between  initial  state,  inputs,  and  the  outputs  produced  at 
some  terminal  state.  These  are  called  relational  or  transformational  systems. 

Most  capabilities  in  the  traditional  hull,  machinery  and  electrical  (HM&E)  areas 
are  produced  by  relational  systems.  A  number  of  examples  can  be  given  as  follows.  In 
Figure  5,  suppose  one  of  the  action  paths  corresponds  to  the  hull.  The  action  modules 
of  hull  systems  determine  such  factors  as  ship  displacement,  corrosion  resistance,  load 
bearing  capacity,  watertight  integrity,  and  stability.  Control  resources  include  ballast, 
watertight  doors,  tankage,  piping,  and  pumps.  Sensing  functions  include  determination 
of  fluid  levels,  trim,  reserve  buoyancy,  and  hazards  to  navigation.  Use  of  a  single 
action  path  to  represent  all  of  the  systems  and  capabilities  involved  makes  for  a  simple 
picture,  but  with  a  modular  structure  that  allows  zooming  in  to  a  more  detailed  model 
when  desired. 
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Returning  to  Figure  5,  let  a  second  action  path  now  correspond  to  ship 
machinery.  The  action  modules  for  machinery  systems  include  pumps,  engines,  and 
transducers  used  to  lift,  steer,  and  propel  the  ship's  hull  and  many  items  of  supply 
contained  within  it.  Sensing  functions  measure  machine  state  parameters,  and  control 
functions  alter  those  states.  To  complete  the  picture,  let  a  third  action  path  correspond 
to  ship  services.  In  particular,  consider  electrical  power.  The  shipboard  electrical 
power  subsystem  must  sense  demand  load,  configure  appropriate  paths  for  distribution, 
and  generate  appropriate  supplies  of  power.  Other,  similar  systems  must  generate  and 
distribute  berthing,  air  conditioning,  compressed  air,  electrical  power,  food,  potable 
water,  chilled  water,  refrigeration,  medical  services,  and  other  resources  necessary  to 
keep  both  people  and  machines  reasonably  healthy  and  productive.  In  a  highly 
simplified  way,  then,  the  figure  can  be  regarded  as  a  model  for  ship  HM&E  resources. 

A  ship  also  contains  many  processes  of  a  second  type,  which  is  called  reactive. 
These  processes  are  designed  to  maintain  some  interaction  with  their  environment, 
terminating  only  if  the  system  should  fail.  Since  there  is  no  natural  terminal  state, 
reactive  processes  cannot  be  described  by  a  simple  relation  that  specifies  output  as  a 
function  of  input.  Instead,  they  must  be  described  in  terms  of  ongoing  behavior.  Useful 
descriptions  typically  involve  complex  sequences  of  events,  actions,  conditions,  and 
information  flows,  often  with  explicit  timing  constraints,  that  combine  to  form  process 
overall  behavior. 

Both  cooperative  and  adversarial  interactions  with  external  entities  are  reactive 
in  character.  A  reactive  process  is  said  to  be  reflexive  when  human  control  is  limited  to 
supervisory  functions,  direct  control  being  automated.  Basic  interactions  involve  one 
entity  and  one  system  and  cannot  be  decomposed  further.  Composite  interactions 
involve  multiple  system-entity  pairings  and  can  be  decomposed  into  a  set  of  basic  or 
composite  interactions,  combined  sequentially,  simultaneously,  independently,  or 
recursively. 

Target  processing  systems  of  all  types  are  largely  reactive  in  nature.  Long-range 
strike  makes  a  useful  example  because  a  centralized  planning  approach,  with 
decentralized  execution,  is  readily  implemented.  A  relational  model  is  appropriate  to 
describe  a  typical  destroyer's  role  in  such  operations,  which  is  to  generate  one 
component  of  a  strike  in  compliance  with  orders.  But  the  overall  strike  is  reactive,  a  fact 
which  becomes  evident  when  the  total  cycle  time  from  detection  to  destruction  is  ’ 
considered.  The  required  interaction  is  accurate  delivery  of  ordnance  against  a  set  of 
targets  that  count."  Changes  in  target  location  or  background,  weather  conditions,  and 
availability  of  target  intelligence  give  this  interaction  a  dynamic  character.  Since  cycle 
time  must  eventually  be  reduced  to  deal  effectively  with  relocatable  targets,  a  relational 
model  could  produce  systems  with  limited  growth  potential.  The  movement  of  fleets 
and  the  conduct  of  tactical  maneuvers  in  meeting  engagements  also  involve  reactive 
processes.  Figure  6  shows  multiple  clusters  of  target  processing  action  paths, 
organized  by  warfare  mission  area.  Figure  7  is  a  simplified  view  of  a  reference  model 
for  a  complete  combat  system.  The  illustration  is  simplified  by  showing  only  a  few 
mission  areas,  and  only  a  few  action  paths  within  each  mission  area. 
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FIGURE  6.  MULTIPLE  ACTION  PATHS  IN  A  SINGLE 
WARFARE  MISSION  AREA 


Cooperative  interactions  can  involve  external  entities  (friendly  units)  or  internal 
entities  (own  ship  systems  and  users).  In  this  case  the  first  set  of  action  paths  might 
provide  for  external  communications  and  the  second  for  internal  (to  include  voice,  video 
and  interprocess  communications).  A  third  set  of  action  paths  corresponds  to  informal 
communications,  not  only  interpersonal  voice  and  visual  but  also  those  associated  with 
command  presence  as  well.  This  appears  sufficient  to  establish  a  notional  reference 
model  for  cooperative  interactions,  similar  to  those  given  for  relational  and  target 
processing  capabilities  above.  However,  such  tasks  as  formation  maneuvering, 
cooperative  engagement,  and  replenishment  may  also  be  considered. 

Air,  surface,  and  undersea  vehicles  of  various  types  can  also  be  operated  from 
surface  ships.  Associated  processes  mirror  the  breakdown  of  shipboard  processes. 
Preparation  for  launch,  launch,  and  transit  processes  are  largely  relational  in  character. 
Reactive  processes  are  generated  in  such  tasks  as  payload  delivery  and  landing. 

Layered  Network  of  Modules 

Figure  7  shows  the  reference  model  as  a  network  of  modules  arranged  in  three 
layers.  The  first  layer  (bottom)  consists  of  action  paths  shown  as  strings  of  functional 
modules  (Sense,  Control,  Act).  The  second  layer  (middle)  provides  for  coordination  of 
mission  areas,  each  formed  on  a  set  of  action  paths  grouped  by  task  category,  plus  an 
appropriate  set  of  coordination  (Cd)  functions.  This  permits  separate  coordination  and 
control  functions  in  each  mission  area  so  that  simultaneous  multiwarfare  operations  can 
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FIGURE  7.  COMBAT  SYSTEM  FUNCTIONAL  REFERENCE  MODEL 


be  conducted.  Action  paths  can  be  grouped  in  many  different  ways  with  little  effect  on 
the  conceptual  framework.  The  third  layer  (top)  is  the  unit  command  level,  where 
objectives  are  established  and  resources  assigned  to  coordinate  their  accomplishment. 
Within  each  layer,  functional  requirements  are  divided  into  the  following  components: 

•  Task  Coordination-lmproves  overall  mission  performance  by  coordinating 
action  paths  to  avoid  waste  and  interference 

•  Information  Coordination-Supports  handling  archival  as  well  as  tactical 
information,  including  communications  with  higher  command  authorities 
and  cooperating  tactical  units.  Information  is  inherently  a  shareable 
resource  and  offers  many  opportunities  for  improved  performance  through 
cueing,  fire  coordination,  or  resource  management. 

•  Resource  Coordination-Includes  key  setup  functions  in  the  mission  areas 
(e.g.,  resource  allocation)  that  establish  which  of  the  realizable  action  paths 
are  active  and  ready.  Performance  gains  can  also  be  sought  by  sharing 
components  between  action  paths  or  systems.  The  basic  idea  is  to  allow 
any-to-any  interconnection  of  functional  components.  For  example,  the 
primary  sensor  of  one  weapon  system  might  be  used  to  support  secondary  or 
backup  sensing  functions  of  another  weapon  system.  Examples  can  be 
constructed  in  such  areas  as  flight  operations,  configuration  control,  and 
training. 

Both  information  and  resource  coordination  are  subordinate  to  the  task 
coordination  function.  These  functions  can  be  allocated  to  different  individuals  if 
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necessary  to  ensure  the  task  coordinator  is  not  overburdened.  Figure  8  shows  the 
reference  model  extended  to  the  total  ship  level.  The  approach  is  based  on  Reference 
34.  The  broad  mission  areas  shown  represent  the  combat,  HM&E,  and  C^l  categories 
of  action  paths.  In  the  HM&E  category,  the  S  -  D  -  L  path  represents  electrical  systems, 
which  must  Sense  demand  and  Distribute  energy  to  Load  centers.  The  R  -  D  -  A  path 
represents  a  generic  resource  management  loop  which  must  generate  a  Resource, 
control  its  Distribution,  and  support  end  user  Access.  In  the  C^l  category,  the  R  -  P  -  T 
path  corresponds  to  sensor  Receive,  Processing,  and  Tracking.  The  I  -  P  -  O  path 
represents  Input,  Processing,  and  Output  by  computing  systems.  The  R  -  P  -  S  path 
represents  message  Receive,  Process,  and  Storage  by  a  communications  system. 

The  examples  are  given  only  to  indicate  the  variety  of  functions  which  can  be 
accommodated  by  the  sense  -  control  -  act  paradigm. 


FIGURE  8.  TOTAL  SHIP  FUNCTIONAL  REFERENCE  MODEL 


As  suggested  by  Figures  7  and  8,  not  only  action  paths  but  also  information  and 
command  paths  are  found  in  warships.  Information  paths  form  the  interconnection 
structure  for  data  flows  within  the  ship.  Command  paths  form  the  command  hierarchy, 
projecting  command  authority  throughout  the  ship.  The  information  and  command 
paths  create  a  potential  for  information  and  resource  sharing  which  is  essential  to 
integration  and  affordability  characteristics  of  future  ships. 


INFORMATION  STRUCTURES 

The  structure  of  mission  information  flows  is  driven  by  decisions  about  ship  battle 
organization  and  operational  roles  of  the  watch  standers.  However  made,  these 


25 


NSWCDDArR-95/152 


dscisions  support  thre©  principal  obj6ctiv6s.  The  first  is  to  support  the  making  of 
information  decisions  by  structuring  flows  of  information  and  advice  to  the  commander. 
The  second  is  to  support  operational  decision  making  by  structuring  the  flows  of 
information  among  the  mission  teams.  The  third  is  to  aid  execution  of  operational 
decisions  by  establishing  a  chain  of  command.  In  particular,  the  necessary  decisions 
and  the  watch  standers  who  make  them  must  be  identified.  The  existence  of  three 
distinct  aims  in  organizational  decision  making  leads  to  creation  of  three  distinct  control 
path  types  in  the  control  structure.  Presence  of  the  different  path  types  has  great 
importance  for  the  integration  and  affordability  properties  of  the  combatant. 

On  the  information  (input)  side  of  their  decision  making,  watch  standers  want  to 
tap  whatever  sources  can  provide  needed  information  without  being  at  the  mercy  of  a 
single  source  for  any  particular  kind  of  information.  To  support  this  aim,  two  types  of 
control  paths  are  created.  Command  paths  support  the  aim  of  structuring  the  flow  of 
information  and  advice  to  the  commander  from  on-board  and  off-board  sources.  They 
also  project  command  authority  throughout  the  ship,  providing  for  two-way  flow  of 
orders  and  status  reports.  One  implication  of  the  hierarchical  approach  is  that  work  unit 
structure  determines  the  subordinates  to  whom  orders  will  be  directed.  Although  the 
decisions  made  at  each  echelon  are  intended  to  direct  operations  at  the  scene  of 
action,  orders  are  normally  directed  for  action  to  personnel  only  at  the  next  lower 
echelon. 

Information  paths  structure  the  flow  of  information  among  task  teams,  from 
sensing  resources  (including  communications)  to  watch  standers.  For  off-board 
sources,  the  operational  chain  of  command  will  also  define  the  chain  for  validating  and 
prioritizing  information  requirements;  when  the  operational  chain  of  command  changes, 
so  does  the  path  for  seeking  information  support.  Because  information  can  be  shared 
across  different  locations,  information  paths  also  knit  shipboard  task  teams  into  the 
joint-foice  command  structure.  Accordingly,  flexibility  in  forming  information  flow  paths 
is  important  for  future  ships. 

On  the  execution  (output)  side,  the  objective  of  organizational  decisions  usually 
is  to  achieve  unity  of  effort  in  the  execution  of  decisions.  How  a  commander  thinks  that 
unity  of  effort  depends  on  unity  of  command  will  be  reflected  in  how  the  commanding 
officer  and  tactical  action  officer  are  linked  to  individual  action  paths.  In  practice,  the 
mission-oriented  control  structure  must  support  two  sets  of  tasks,  warfighting 
coordination  and  readiness  coordination.  The  first  provides  supervisory  control  of 
tactical  operations  and  definition  of  task  objectives  for  subordinate  mission  areas. 
Related  tasks  include  implementation  of  command  doctrine  to  detect,  localize,  and  track 
targets:  threat  evaluation;  and  maintaining  a  tactical  picture.  The  objective  in  readiness 
coordination  is  to  balance  resources  against  tasks,  equalizing  stress  on  all  parts  of  the 
organization.  This  entails  (a)  loading  and  balance  controls  for  key  operating  tasks  and 
(b)  resource  management  and  configuration  controls.  Associated  tasks  include 
resource  allocation  and  monitoring  in  each  subordinate  mission  area,  establishing 
which  of  all  possible  action  paths  are  ready  for  use. 
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CONTROL  STRUCTURES 

Ship  control  structures  are  strongly  influenced  by  two  factors:  mission  tasks  and 
available  technology.  Since  industrial  controls  respond  to  the  same  technical  trends,  it 
is  worthwhile  to  take  an  occasional  look  at  the  path  followed  by  industry.  A  design 
strategy  called  Dynamic  Process  Control  evolved  during  the  1960s,  and  with  its 
formulation  in  Reference  35  came  to  be  accepted  as  the  dominant  approach  to  control 
systems.  Control  actions  were  divided  into  two  categories,  those  needed  to  achieve 
material  balance  control  throughout  the  plant  and  those  needed  to  maintain  product 
quality  control  for  each  individual  processing  unit.  The  former  was  necessary  for  plant 
management  in  the  presence  of  low-frequency  changes  like  production  scheduling  and 
could  be  designed  separately  from  the  latter,  which  was  intended  to  regulate  high 
frequency  disturbances  entering  the  various  units.  In  simple  terms,  overdesign 
margins,  storage  buffers,  and  load  smoothing  were  used  to  keep  loading  and  balance 
controls  simple.  Designers  were  thus  able  to  focus  on  controls  for  the  individual 
operating  units.  This  gives  a  bottom-up  design  approach  similar  to  that  used  by  the 
Navy. 


This  strategy  worked  very  well  until  new  economic  constraints  came  into  play. 
First,  shortages  of  raw  materials  and  energy  appeared.  These  shortages  led  to  new 
integrated  designs  with  better  energy  management  and  more  use  of  recycle  flows  in  a 
plant.  Second,  restrictions  appeared  on  fixed  capital  budgets.  The  reduced  budgets 
led  to  lean  processing  units,  with  very  small  overdesign  margins,  and  elimination  of 
storage  buffers.  Plant  operating  units  came  to  be  tightly  coupled  via  energy  recovery 
systems  and  recycle  flows.  Thus  it  became  necessary  to  address  control  structures  for 
entire  plants,  rather  than  individual  operating  units.  The  complete  plant  approach  is 
outlined  in  References  36  and  37. 

Adapting  to  reduced  capital  budgets  is  clearly  important  for  the  surface  ships 
domain.  Energy  management  and  recycle  flows  are  less  important,  but  the  problem  of 
rationalizing  information  flows  presents  a  similar  set  of  problems.  Overall,  it  appears 
that  surface  ship  design,  acquisition,  and  construction  may  benefit  from  process 
improvements  as  much  as  other  enterprises  have  done.  As  Reference  38  suggests,  an 
era  of  fundamental  change  in  productive  systems  and  methods  is  now  underway. 
Leading  commercial  enterprises  now  envision  a  system  of  tightly  integrated  loops 
connecting  all  key  parties  to  a  transaction  (customer,  producer,  distributor  and  payment 
agency).  Underpinning  these  loops  will  be  systems  of  lean  production  that  use  less  of 
everything  compared  with  the  mass  production  systems  of  the  past:  half  the  human 
effort  in  half  the  space,  and  half  the  engineering  effort  to  develop  new  products  in  half 
the  time.  Plants  will  be  designed  to  gain  efficiency  levels  bordering  on  perfection  and  to 
achieve  high  product  variety  with  continually  declining  costs,  zero  defects,  and  zero 
inventories.  Virtually  every  enterprise  that  depends  on  large  and  complex  productive 
systems  is  exploring  ways  to  pursue  a  similar  vision.  The  call  for  total  ship  system 
engineering  may  be  simply  a  call  for  some  parallel  movement  in  the  surface  ship 
domain. 
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CHAPTER  4 

REINVENTING  SHIP  CONTROL  STRUCTURE 


Each  chapter  of  this  report  reflects  the  premise  that  future  Navy  ships  should  be 
designed  from  a  total  ship  perspective  to  serve  as  elements  of  a  capable  and  jointly 
interoperable  Navy  warfighting  system.  Chapter  1  notes  that  total  ship  engineering 
begins  with  the  idea  that  a  warship  must  act  as  a  coherent  warfighting  system,  all  parts 
working  in  unison  to  maximize  operational  effectiveness.  From  hull  form  to  launchers 
and  missiles,  every  part  of  the  ship  must  contribute  to  the  overall  goal  of  ordnance  on 
target.  Chapter  2  argues  that  future  designs  must  weave  combat,  support,  hull,  and 
machinery  modules  into  a  system  of  systems  configuration  with  a  mix  of  firepower, 
stealth,  survivability,  and  affordability  characteristics  that  meets  all  operational 
requirements.  This  demands  efforts  to  establish  a  comprehensive  system  engineering 
framework  for  ships.  Chapter  3  provides  a  domain  reference  model  for  surface  ships, 
indicating  that  control  structure  drives  the  ship's  ability  to  act  as  a  coherent  entity.  This 
chapter  considers  what  the  control  structure  of  a  surface  ship  should  be,  from  a  top- 
down  perspective. 


POINT  OF  DEPARTURE 

The  strategy  for  partitioning  control  resources  on  a  total  ship  basis  is  rooted  in 
basic  principles  of  system  engineering.  The  first  principle  to  be  considered  is  that  the 
aim  of  design  must  be  to  help  the  warfighters  in  achieving  their  operational  objectives. 
The  mission  teams  carried  to  an  operating  area,  where  they  may  be  called  upon  to 
maintain  presence  or  to  deliver  high-tech  firepower  against  an  adversary,  must  be  the 
primary  concern.  The  principal  outcome  desired  in  total  ship  system  engineering  is  to 
build  ships  that  will  (a)  meet  the  needs  of  the  on-board  mission  teams  and  (b)  enable 
on-board  teams  to  contribute  effectively  to  other  mission  teams  within  the  battle 
organization  established  by  a  theater  level  commander. 

In  future  conflicts,  these  teams  will  face  multiwarfare  threats  in  difficult 
operational  environments,  and  expeditionary  operations  with  joint,  allied,  and  coalition 
forces  will  be  emphasized.  Beyond  this,  as  Figure  9  suggests,  ship  roles  and  tasks  are 
characterized  more  by  uncertainty  than  any  other  single  feature.  To  support  mission 
teams  under  these  circumstances,  ships  must  be  flexible,  capable  of  tailoring  basic 
capabilities  to  a  designated  set  of  mission  tasks  and  operating  environments.  They 
must  also  be  able  to  operate  as  an  integral  part  of  joint  or  coalition  expeditionary  forces. 
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FIGURE  9.  WHAT  FUTURE  SHIPS  MUST  DO 


Given  the  rapid  pace  of  technical  progress,  the  ongoing  “revolution  in  military  affairs,” 
and  the  importance  of  affordability,  use  of  open  system  designs  must  also  be 
emphasized. 

A  second  key  principle  of  system  engineering  is  that  systems  should  be 
partitioned  so  that  the  major  subsystems  created  are  loosely  coupled  (weakly 
interacting).  The  approach  is  therefore  based  on  considerations  of  domain  clarity  and 
distinctiveness,  stability  of  domains  and  associated  interfaces,  and  minimal  crossover 
(i.e.,  each  module  should  interact  weakly  with  other  modules).  The  importance  of  this 
last  property  is  that  where  it  applies  a  designer  can  change  one  part  of  a  system 
without  creating  a  cascade  of  compensatory  changes  to  other  parts.  When  the  internal 
state  of  one  module  has  a  strong  bearing  on  the  internal  state  of  other  modules, 
decomposition  could  complicate  rather  than  simplify  the  design  problem. 

Following  the  principles  cited,  the  question  of  partitioning  for  total  ship  command 
and  control  is  considered  below  from  a  warfighter's  point  of  view.  Regardless  of  the 
approach  to  spatial  arrangement  and  physical  modularity,  a  control  structure  is 
necessary  to  make  ships  responsive  to  command  direction  and  control.  In  defining  a 
framework  for  design  of  control  structures  on  a  total  ship  basis,  we  start  with  the  simple 
view  of  warships  shown  in  Figure  10.  This  view  shows  people  at  the  top,  mission 
resources  at  the  bottom,  and  control  interfaces  (or  command  and  control  interfaces)  in 
between.  The  control  interfaces  provide  a  backbone  structure  that  links  mission  teams 
with  the  resources  necessary  to  perform  assigned  tasks  and  make  the  mission 
resources  responsive  to  human  direction  and  control. 
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Total 
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FIGURE  10.  POINT  OF  DEPARTURE  FOR 
TOTAL  SHIP  ENGINEERING 


At  one  time,  resources  were  under  direct  control  of  the  warfighters.  Training  a 
gun  or  changing  a  fuel  flow  rate  meant  repositioning  a  lever  or  valve.  Today,  computing 
systems  are  widely  used  for  control  functions.  While  the  number  of  people  involved  is 
somewhat  less,  what  warfighters  must  do  remains  the  focus  of  attention.  Only  under 
direction  of  its  mission  teams  does  a  ship  become  a  complete  warfighting  system,  a 
combatant,  capable  of  acting  on  its  own  to  achieve  a  designated  military  purpose. 

Even  a  fully  automated  ship  would  execute  broad  plans  and  orders  from  a  human 
commander. 


PARTITIONING  OF  CONTROL  LAYER 

From  a  warfighting  point  of  view,  the  first  concern  is  the  military  purpose  of  the 
ship  and  its  intended  operational  use.  For  surface  combatants,  this  means  putting 
ordnance  on  target.  For  amphibious  and  auxiliary  types,  it  may  involve  (among  others) 
sealift,  amphibious  assault,  mine  countermeasures,  or  command  support  operations.  In 
any  case,  command  elements  must  govern  the  operation  of  mission-critical  systems 
and  their  interactions  so  that  the  ship  can  accomplish  its  fundamental  military  purpose 
with  efficiency  and  dispatch.  A  second  important  concern  is  posturing  the  ship  for 
operations  through  readiness  assessment  and  resource  management.  In  a  broad 
sense,  what  is  involved  here  is  to  provide  for  integrated  command  and  control  of  own 
ship  mission  operations,  readiness  posture,  and  information  flows.  An  expanded  view 
of  this  structure,  regarded  as  a  top-level  partitioning  for  overall  control  responsibilities,  is 
shown  by  Figure  1 1 .  Rationale  for  this  partitioning  is  considered  below.  The  structure 
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FIGURE  11.  LAYERED  CONCEPT  FOR  TOTAL  SHIP 
SYSTEM  OF  SYSTEMS 


Shown  is  quite  general  in  nature,  and  use  of  the  term  “mission  operations”  makes 
application  to  amphibious  and  auxiliary  ship  types  a  fairly  simple  variation. 

However,  the  final  test  must  be  whether  it  captures  what  is  most  important  to  command. 
A  number  of  experienced  commanders  and  trainers  should  be  consulted  to  ensure  the 
chosen  structure  is  consistent  with  Navy  doctrine  and  operationally  effective. 

Uncertainty  is  the  central  factor  with  which  all  command  and  control  systems 
must  deal,  and  a  major  factor  in  selecting  an  appropriate  control  structure.  In  general, 
the  more  important  the  human  element  in  a  given  situation,  as  opposed  to  the  technical 
and  the  more  important  enemy  actions  are  in  shaping  that  situation,  the  greater  the 
uncertainty  involved.  Ship  containment,  mobility,  and  support  systems  thus 
tend  to  be  organized  by  function  and  controlled  in  a  top-down  fashion,  and  the  chief 
concern  is  to  keep  essential  operating  and  support  systems  ready  to  act  when  needed. 


The  chief  concern  in  combat  operations  is  to  carry  out  essential  mission  tasks; 
maneuvering,  fighting,  and  cooperative  interaction  with  other  units.  The  combat 
resources  are  thus  organized  by  mission  area  and  every  effort  is  made  to  preserve 
freedom  of  action  at  the  bottom  of  the  command  structure.  Combat  operations  tend  to 
call  for  more  intensive  use  of  information,  and  may  demand  a  greater  share  of 
command  attention  than  tasks  associated  with  ship  systems.  Thus,  different  organizing 
principles  are  appropriate  in  the  two  domains,  and  they  generally  have  separate  work 
units  in  ship  command  structures.  Indeed,  relatively  little  attention  has  so  far  been 
given  to  automated  means  for  integrating  ship  command  functions  across  the  two 
domains.  Today,  it  is  widely  recognized  that  the  boundary  lines  between  them  are 
shifting,  maneuver  control  and  damage  control  coordination  are  increasingly  important 
concerns  that  may  move  across  this  boundary. 
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A  third  domain,  information  coordination,  allows  command  to  interact 
purposefully  with  on-board  or  off-board  correspondents.  In  addition,  it  accommodates 
changes  in  command  and  control  structure  by  reconfiguring  information  flow  paths. 
Confronted  with  a  task,  and  having  less  information  than  is  needed  to  perform  that  task, 
an  organization  may  react  in  either  of  two  ways.  One  is  to  redesign  the  work  process 
(and  organization)  in  such  a  way  as  to  permit  effective  action  with  less  information.  The 
alternative  is  to  increase  the  information  processing  capacity.  Both  methods  produce 
changes  in  system  information  flows.  This  may  involve  changes  in  decisions  and 
reports,  in  terms  of  what  decisions  and  reports  are  made  or  in  terms  of  who  makes 
them.  It  can  also  mean  changes  in  task  organization  and  internal  communication 
patterns,  or  reallocation  of  resources  to  get  essential  information  through  new  sources 
and  methods. 

A  separate  work  unit  is  needed  for  information  coordination  because  it  involves  a 
service  that  supports  both  of  the  other  domains.  The  way  we  design  and  build  today's 
surface  combatants  reflects  a  hidden  assumption  that  information  and  control  flows  are 
relatively  static.  We  may  expect  the  data  in  these  flow  paths  to  change  as  orders  are 
received,  the  tactical  situation  evolves,  and  ordnance  is  expended;  but  we  do  not 
expect  or  provide  for  redefining  the  way  system  tasks  are  performed  and  coordinated. 
But  configuration  changes  may  be  needed  for  a  variety  of  reasons.  Reconstitution  or 
upgrade,  use  of  services  from  systems  on  other  platforms,  and  evolution  of  design 
baselines  mean  changes  that  can  redefine  system  characteristics  over  a  long  time  line. 
Shifts  in  operational  modes  and  threats,  battle  damage,  equipment  failures,  and  the 
desire  to  tailor  operating  modes  to  specific  operating  environments  may  call  for 
corresponding  changes  to  a  ship's  patterns  of  information  flow. 

With  modern  designs,  however,  the  assignment  of  resources  to  a  given  action 
path  need  not  be  a  fixed  characteristic  of  the  design.  Resource  assignments  may  be 
dynamic,  varying  with  assigned  missions  and  tasks  at  any  point  in  time.  Design  of 
system  elements  for  any-to-any  interconnection  can  support  a  virtually  unlimited 
repertory  of  subsystem  and  segment  configurations,  with  flexibility  to  create  new 
operating  modes  tailored  to  specific  operating  tasks  and  roles.  A  large  repertory  of 
configurations  and  capability  profiles  can  enhance  a  commander's  ability  to  achieve 
surprise  in  tactical  operations  and  thus  dictate  the  terms  of  action.  Reconfigurable  data 
and  control  paths  also  create  opportunities  for  increased  survivability  and  growth 
potential  compared  to  fixed  path  designs.  Creation  of  a  separate  information 
coordination  backbone  (as  discussed  in  the  next  section)  can  make  future  surface 
combatants  better  able  to  continuously  redefine  information  and  control  flows  by 
altering  interconnection  structures. 


BACKBONE  ROLES  AND  CHARACTERISTICS 

How  the  control  structure  is  formed  plays  an  important  role  in  defining  and 
controlling  the  development  of  a  warship  as  a  system  of  systems.  Just  as  the  domain 
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model  of  Chapter  3  permits  a  common  understanding  of  goals  and  requirements  at  the 
level  of  individual  systems,  consideration  of  backbone  roles  and  characteristics 
promotes  a  common  understanding  of  how  control  functions  and  interfaces  should  be 
handled.  An  expanded  view  of  features  envisioned  for  the  mission  operations,  plant 
control,  and  information  flow  control  backbones  is  thus  given  below. 

Mission  Operations.  A  ship’s  battle  organization  typically  contains  several  mission 
teams,  each  capable  of  performing  some  essential  mission  task.  The  mission 
operations  backbone  must  provide  a  common  framework  linking  these  warfighting 
teams  to  ship  resources  and  supporting  the  use  of  those  resources  to  achieve  the 
ship's  fundamental  military  purpose.  This  backbone  provides  the  control  structure 
necessary  to  fight  the  ship  as  a  unified  and  robust  operating  entity  and  must  enable  the 
command  team  to  integrate  all  aspects  of  target  processing  with  tactical  maneuvers, 
cooperative  interactions  with  other  units,  and  damage  control  coordination  as 
necessary  for  effective  mission  operations.  Key  internal  considerations  include  how  the 
ship  will  be  organized  for  maximum  effectiveness  across  its  key  mission  roles  and 
tasks.  This  involves  battle  organization,  mission  planning,  and  tactical  maneuvering 
capabilities.  Key  external  considerations  include  how  the  ship  is  organized  to  deal  with 
external  partners,  clients,  and  competitors.  In  particular,  the  overall  command  structure 
for  naval  forces  in  the  theater  of  operations  must  be  considered. 

However,  the  mission  operations  backbone  would  differ  in  several  ways  from 
today's  combat  systems.  It  is  intended  to  control  all  aspects  of  actual  warfighting,  to 
include  such  tasks  as  tactical  maneuvering  and  damage  control  coordination,  long 
considered  elements  of  HM&E.  Training  and  readiness  management  tasks,  which  are 
assigned  elsewhere,  may  be  replaced  by  such  tasks  as  control  of  operations  by 
embarked  vehicles,  likely  to  involve  surveillance  and  fire  control  support.  The  result  will 
be  a  system  of  systems  that  includes  most  combat  capabilities,  but  with  changes 
appropriate  to  contemporary  notions  of  combat  operations.  In  contrast  with  today's 
systems,  however,  it  is  envisioned  that  the  warfare  mission  areas  will  employ  a 
common  operating  environment,  limiting  the  use  of  noncommon  features  to  mission- 
specific  applications. 

Readiness  and  Riant  Controi.  The  readiness  and  plant  control  backbone  is  intended  as 
a  common  framework  for  transforming  the  ship's  physical  resources  into  ready 
capabilities  for  use  by  warfighting  teams  in  achieving  mission  objectives.  This 
backbone  must  provide  for  continuous  availability  of  essential  warfighting  capabilities 
even  if  system  failures  occur  or  battle  damage  is  present.  Design  emphasis  must  be 
given  to  features  enabling  the  crew  to  operate  and  maintain  tactical  systems  at  design 
performance  levels  despite  the  harsh  physical  environments,  imperfect  logistics,  and 
fallibility  of  both  human  and  machine  systems  that  must  be  expected  in  joint  and 
expeditionary  warfare  operations.  Key  internal  considerations  include  organization  and 
optimization  of  resources  within  and  across  functional  areas,  and  optimizing 
relationships  between  functions.  Key  external  considerations  include  logistic  support 
planning  and  access  to  remote  services,  such  as  test  and  maintenance  assistance. 
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Information  Flows.  A  third  backbone  is  needed  to  set  up  and  coordinate  information 
flow  paths  within  the  ship.  The  chief  concern  is  to  allow  individual  systems  to  interact 
purposefully  with  on-board  or  off-board  elements  or  systems.  The  intent  is  to  create  a 
utility  that  coordinates  information  flows  throughout  the  ship,  but  leaves  actual  use  of 
the  resources  provided  to  individual  mission  teams.  This  includes  coordination  of  the 
mission-oriented  flows  necessary  for  combat  operations:  the  function-oriented  flows 
necessary  for  plant  control;  and  any  summary  information  necessary  for  command.  It 
also  provides  for  coordinated  use  of  the  inherently  shareable  information  provided  by 
communications,  computing,  and  sensing  systems.  Technology  will  permit  dynamic 
reconfiguration  of  information  flow  paths  in  future  warships,  and  mission  requirements 
will  dictate  that  this  potential  flexibility  be  exploited.  The  potential  for  a  doctrine-driven 
approach  is  significant. 

An  important  feature  of  information  systems  is  that  service  attributes  are  a 
driving  factor  in  system  organization.  Surface  combatants  have  many  subsystems,  with 
various  elements  exchanging  data  to  achieve  coordinated  action.  The  subsystems  will 
differ  in  attributes  such  as  time  criticality,  system  integrity,  modes  of  communication, 
security,  certification,  granularity,  and  perishability  of  data.  It  can  be  expected  that 
information  flow  paths  will  be  divided  into  several  segments  to  keep  within  the  capacity 
of  standard  networks  (including  design  margins  to  allow  for  latency  requirements  and 
system  expansion).  Elements  with  similar  attributes  will  be  placed  in  the  same  segment 
where  possible,  and  intersegment  flows  will  be  minimized.  In  short,  information  flow 
paths  ought  to  be  organized  by  service  attributes,  rather  than  mission  tasks  or  functions 
as  in  the  mission  operations  and  plant  control  domains. 

The  maturation  of  distributed  computing  technology  may  be  the  occasion  for 
significant  improvements  in  configuration  flexibility.  Distributed  computing  typically 
demands  a  high  level  of  configuration  management  capability  because  of  the  frequency 
of  field  reconfiguration  and  upgrade  actions.  Configuration  management  tools  are  used 
to  define  node  addresses  and  relationships  between  nodes,  add  new  nodes  and 
replace  any  which  are  defective  or  obsolete,  and  test  nodes  or  functions  necessary  to 
properly  start  up  and  maintain  systems  and  processes.  These  configuration 
management  requirements  tend  to  come  as  a  surprise  to  many  people  moving  from 
centralized  to  distributed  computing  architectures;  earlier  systems  never  had  to  replace 
or  even  to  address  nodes.  Relationships  between  nodes  were  determined  by 
algorithms  programmed  into  the  central  control  unit.  Change  meant  costly 
modifications  to  system  wiring  and  access  to  system  integration  expertise.  But  the 
"necessary  evil"  of  system  management  is  really  an  enabling  tool  to  harness  the  new 
potential  of  distributed  systems  for  improved  configuration  flexibility  and  ease  of 
maintenance. 

One  application  of  this  new  potential  is  to  make  embedded  control  capabilities 
more  reliable.  Recent  decades  have  seen  a  trend  to  decentralized  control  structures 
with  static  interconnection  patterns  that  are  quite  vulnerable  to  control  node  failures. 

The  term  "decentralized"  refers  in  this  context  to  the  control  information  pattern.  It 
signifies  that  within  a  given  layer  of  the  control  structure  different  nodes  have  access  to 
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different  (specialized)  information.  For  example,  an  antiair  warfare  coordinator  would 
not  have  access  to  strike  data.  From  the  reliability  point  of  view,  this  approach  relies  on 
series  connection  of  nodes,  yielding  no  redundancy  in  control  capability. 

A  key  principle  of  system  engineering  for  complex  systems  is  that  unreliability  of 
components  should  be  overcome  by  organizing  them  in  such  a  way  that  the  reliability  of 
the  whole  is  greater  than  the  reliability  of  its  parts.  This  is  an  idea  formulated  in  design 
of  reliable  computing  systems  and  extended  to  control  structures  only  recently.  Parallel 
(or  multiplex)  designs  can  be  achieved  in  control  structures  by  using  multiple  control 
nodes.  The  key  is  to  provide  for  multiple  interconnection  paths  so  that  when  one 
controller  fails  the  other  is  capable  of  carrying  on  the  plant.  The  failed  node  can  then 
be  disconnected,  tested,  and  repaired  or  replaced  without  interrupting  system 
operation.  With  the  flexibility  afforded  by  network  technology,  it  becomes  possible  for 
ships  to  continuously  redefine  control  structures  by  activating  new  paths  of  information 
flow. 


STRUCTURAL  FLEXIBILITY 

Shipboard  command  and  control  tasks  involve  at  least  two  levels  of  integration. 
One  is  the  overall  command  level.  Major  design  concerns  at  this  level  include  basic 
organization  of  the  command  team,  integration  of  mission  teams  across  different 
physical  locations,  and  interoperation  (collaborative  work)  with  other  commands.  The 
second  level  is  that  of  mission  teams,  in  which  several  individuals  perform  a  related  set 
of  tasks.  In  general,  task  teams  are  formed  by  one  of  the  following  methods: 

•  Area  (by  grouping  together  all  forces  within  a  geographic  area  from 
whatever  service  or  nation  or  for  whatever  purpose) 

•  Service  or  nation  (by  grouping  in  each  subdivision  all  forces  from  only 
one  service  or  nation) 

•  Medium  (by  grouping  together  all  ground  forces,  air  forces,  and 
seaborne  forces  from  whatever  nation  or  service) 

•  Task  (that  is,  grouping  together  all  forces  directly  involved  in  accomplishing 
the  same  task  from  whatever  service  or  nation) 

Some  organizational  structures  reflect  a  mix  of  these  options.  In  the  recent  past, 
open  ocean  task  force  operations  were  seen  as  the  primary  role  of  naval  forces. 

Surface  combatants  were  organized  by  warfare  mission  area  to  support  the  Navy's 
composite  warfare  command  concept  for  war  at  sea.  Task  and  medium  were  closely 
aligned  as  the  basis  for  this  approach,  and  surface  ships  organized  for  battle  by  warfare 
mission  area  teams.  In  the  future,  surface  ships  may  serve  as  elements  of  naval 
expeditionary  forces,  joint  or  combined  forces,  or  interagency  task  forces  (as  in 
peacekeeping  operations).  Each  of  these  force  types  could  employ  a  different 


36 


NSWCDD/rR-95/152 


command  structure  and  place  a  different  set  of  demands  on  the  ships  involved.  The 
key  question  is  whether  some  command  structure  will  be  generally  useful  for  naval 
forces,  across  all  three  force  organizations,  or  whether  a  variety  of  different  command 
structures  will  be  needed.  In  either  case,  warships  will  probably  mirror  the  preferred 
force  command  structure. 

Littoral  warfare  operations  seem  likely  to  demand  increased  flexibility  in  surface 
ship  command  structures.  Dealing  with  the  littoral  warfare  environment  could  make  it 
necessary  to  alter  how  naval  forces  and  ships  are  organized  to  deal  with  their  external 
partners,  competitors,  and  stakeholders.  Warfighting  and  force  employment  strategies, 
force  composition,  command  structure,  threat,  and  operating  environments  may  vary 
greatly  in  future  conflicts.  In  this  era  of  uncertainty  and  change,  the  battle  organization 
may  need  to  change  to  meet  specific  mission  needs,  make  best  use  of  available 
personnel,  or  exploit  a  particular  tactical  situation.  Two  things  must  be  done  to  meet 
this  challenge.  The  first  is  to  identify  system  engineering  methods  that  allow  a 
satisfactory  design  to  be  created  and  that  can  be  used  to  choose  between  design 
alternatives.  This  will  become  part  of  the  foundation  for  managing  overall  system  life 
cycle  cost  and  integrity.  The  second  is  to  identify  a  design  that  will  support  a  large 
measure  of  operational  flexibility. 

While  "big  change"  may  play  out  only  over  many  years,  the  importance  of 
flexibility  can  be  highlighted  by  scenarios  for  change.  One  scenario  calls  for  a 
command  team  structured  to  deal  with  power  projection,  battle  space  dominance,  C^S- 
information  warfare,  survivability,  and  mobility  as  the  major  operational  tasks  to  be 
performed.  The  important  consideration  for  this  discussion  is  that  the  creation  of  any 
new  mission  structure  requires  a  corresponding  realignment  of  the  battle  organization. 
A  variety  of  special  purpose  teams  may  also  have  to  be  supported.  For  example,  this 
could  include  formation  of  a  joint  air  identification  team;  integration  of  a  US  Marine 
Corps  air  defense  control  team,  using  embarked  rather  than  organic  facilities,  into  the 
ship's  combat  control  structure;  and  embarkation  of  a  Force  AAW  Commander  and 
staff.  Other  examples  are  easily  added  to  the  list.  Indeed,  each  forward  deployment 
cycle  might  call  for  a  different  command  structure  or  variation  from  some  core  structure. 
It  could  also  be  necessary  to  adapt  to  changes  in  the  structure  of  joint  commands  as  a 
conflict  situation  evolves.  A  design  that  makes  physical  rearrangement  of  warfighting 
teams  and  work  stations  easy  is  then  important.  Decision  aids  (such  as  templates)  for 
tailoring  a  ship's  command  structure  to  specific  mission  needs  represent  a  second  step 
fonward  in  flexibility. 

An  open  systems  approach  facilitates  change.  The  initial  design  should  be 
viewed  as  the  nucleus  of  a  more  advanced  or  larger  system,  with  hooks  installed  to 
support  change  scenarios.  Direct  and  dedicated  support  should  be  provided  for  a 
range  of  alternative  battle  organizations,  action  options,  information  flow  patterns,  and 
tactical  procedures,  tailoring  ship  capabilities  to  the  designated  mission  and  operating 
environment.  Force  command  roles  depend  on  the  ship's  capabilities  for  external 
communications,  tactical  picture  formation,  and  configuration  to  support  command  and 
control  systems  and  structures  of  expeditionary,  interagency,  joint,  and  allied  forces. 
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Such  operations  demand  the  ability  to  make  ship  resources  available  to  a  shifting  array 
of  coalition  partners  and  tasks.  Heavy  demands  may  be  placed  on  airmanship, 
seamanship,  and  emergency  assistance  skills  as  well  as  ready  mission  capabilities. 
Mission  capabilities  must  include  a  large  repertory  of  options  for  flexible  and  reliable 
performance  of  engagement,  peacekeeping,  tactical  maneuvering,  and  interoperation 
tasks.  It  is  essential  to  accommodate  a  wide  variety  of  operational,  physical,  and  threat 
environments. 


TOWARD  A  SHIPWIDE  CONTROL  ARCHITECTURE 

The  open  systems  paradigm  can  be  applied  to  surface  ships  as  shown  by  Figure 
12.  The  diagram  is  a  variation  of  the  basic  entity-relationship  model  used  in  Reference 
29  to  define  the  NIST  Application  Portability  Profile  and  again  in  Reference  30  to  define 
a  technical  reference  model  for  DoD  information  systems.  The  ship  is  viewed  as  a 
layered  open  system  with  three  entity  types  and  two  interface  types.  The  target 
architecture  represents  a  strategy  for  applying  the  concept  of  open  systems  to  warship 
development.  The  aim  is  combine  the  qualities  of  portability  and  interoperability  sought 
in  open  systems  design  with  the  effectiveness  and  reliability  sought  in  surface 
combatants. 

The  target  architecture  is  layered  to  form  two  loosely  coupled  subsystems.  The 
first  links  application  software  entities  to  application  platform  entities.  As  in  the  NIST 
Profile  the  basic  idea  is  to  make  the  services  provided  by  the  application  platforms  (at 
their  interfaces)  transparent  to  application  software.  This  first  subsystem  is  then  loosely 
coupled,  in  that  application  platform  entities  are  interchangeable  and  application 
software  entities  become  reusable. 


FIGURE  12.  TOTAL  SHIP  TARGET  ARCHITECTURE 
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The  second  subsystem  links  external  environment  entities  to  application  platform 
entities.  Again,  the  basic  idea  is  to  make  services  provided  by  the  latter  (at  their 
interfaces)  transparent  to  individual  sensors,  weapons,  work  stations,  machinery,  and 
service  systems  throughout  the  ship.  Both  application  platform  entities  and  external 
environment  entities  are  viewed  as  providers  of  standard  services,  and  any  two 
elements  providing  equivalent  services  should  be  interchangeable. 

As  indicated  in  Figure  13,  the  benefits  of  a  common  backbone  are  applicable  to 
all  three  backbone  areas  (mission  operations,  plant  control  and  readiness,  and 
information  management).  What  is  envisioned  is  a  generic  backbone  (with  variants 
tailored  to  each  area)  that  supports  design  for  modularity,  commonality,  and  the  sharing 
of  functional  resources  on  a  shipwide  basis.  The  generic  backbone  would  provide  the 
following  characteristics: 

•  Command  spaces  become  utilities,  tailorable  to  any  set  of  mission  teams  and 
tasks  that  may  be  operationally  required. 

•  Computing,  communication,  and  display  resources  are  managed  on  a  shipwide 

basis,  with  a  common  application  environment  maintained. 

•  Resources  and  readiness  characteristics  are  managed  on  a  shipwide  basis. 

•  Life  cycle  costs  are  reduced  through  efforts  to  hold  manning  and  parts  count  to 
minimum  levels  and  adopting  an  open  systems  approach. 


FIGURE  13.  VISION  FOR  TOTAL  SHIP  INTEGRATION 
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Capabilities  sought  in  the  individual  areas  are  identified  in  the  bottom  part  of 
Figure  13.  Overall,  the  resulting  architecture  is  intended  to  be  enduring,  flexible, 
permitting  application  to  a  variety  of  ship  types  and  designs,  easy  insertion  of  ne\w 
functionality  as  warfighting  systems  evolve,  and  insertion  of  new  technology  as  it 
becomes  available.  The  original  backbone  architecture  should  include  an  extension 
framework  and  be  subject  to  formal  change  control  from  the  earliest  stages  of 
development.  Many  of  the  capabilities  envisioned  for  plant  control  and  information 
management  are  described  in  References  20,  39,  and  40. 

Based  on  the  total  ship  engineering  process  and  partitioning  scheme  outlined 
above,  reengineering  opportunities  have  been  addressed  for  the  area  of  mission 
operations.  The  main  question  considered  in  this  effort  was  whether  it  makes  sense  to 
talk  about  a  common  system  engineering  framework  across  many  different  projects  in 
the  combat  system  area,  as  suggested  by  Figure  14.' 


Common  Core  Areas _ 

Computing,  Convns,  Displays 
•  Multipurpose  Team  Wbrk  Stations 
\^lnterfaces -  Human,  SM'  H/W 


'  Data  Structures  &  Systems 
» Mission  Support  Applications 
•  Readiness  Management 


FIGURE  14,  VISION  FOR  COMBAT  SYSTEMS 


Results  indicate  a  common  backbone  structure  may  be  feasible  in  future  combat 
systems.  This  would  mean,  for  the  combat  system  as  a  whole,  the  kind  of  flexibility  and 
resource  sharing  achieved  by  the  Mk  41  VLS  in  handling  multiple  missile  types,  or  by 
the  AEGIS  Weapon  System  in  handling  multiple,  simultaneous  targets.  The  idea  of  a 


Warfare  areas  shown  are  AAW,  antiair;  NSFS,  naval  surface  fire  support;  AMW,  amphibious;  ASW, 
antisubmarine;  CCW,  command  and  control;  STK,  strike;  ASuW,  antisurface;  MIW,  mine. 
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common  operating  environment  (COE)*  is  usually  applied  only  to  a  computing 
environment.  Creating  a  common  backbone  for  mission  operations  (combat  control) 
means  a  COE  defined  more  broadly,  to  include  not  only  computer  resources  but  also 
watch  stations,  interfaces,  communications,  displays,  and  mission  support  applications. 
Common  system  services  should  also  be  provided  to  deal  with  configuration 
management  functions  (such  as  naming,  or  providing  a  common  data  element 
dictionary).  The  backbone  would  provide  a  standards-based  framework  for 
development  and  integration  of  individual  combat  systems.  The  individual  system 
programs  would  then  be  able  to  focus  on  delivery  of  mission-unique  applications  and 
components.  Use  of  an  open  system  framework  can  make  this  both  affordable  and 
capable.  The  potential  benefits  appear  very  significant. 


ALTERNATIVE  PARTITIONING  STRATEGIES 

While  the  concept  shown  in  Figure  1 1  has  been  considered  carefully,  it  is 
important  to  note  that  any  partitioning  corresponds  to  a  particular  view  of  the  system. 
Since  many  viewpoints  can  be  appropriate,  or  even  necessary  given  different  aims,  it  is 
believed  that  alternative  partitioning  approaches  should  be  considered  and  discussed. 
Partitioning  strategies  differ  in  the  dimensions  considered  and  the  importance  assigned 
to  them.  Space  and  time,  mission,  function,  and  service  attributes  are  among  the 
dimensions  most  often  considered.  One  alternative  is  the  work  breakdown 
(department)  structure  used  in  today's  ships.  This  leads  to  partition  elements  such  as 
navigation,  operations,  engineering,  combat,  supply,  medical,  and  administration.  A 
second  alternative  is  formed  by  breaking  the  traditional  HM&E  systems  category  into 
ship  services  and  mobility.  The  partition  elements  are  then  combat,  services,  and 
mobility.  Since  information  services  can  be  treated  as  only  one  among  many  services, 
this  approach  may  be  workable.  After  long  dialog,  debates  about  partitioning  tend  to 
turn  into  naming  contests,  with  little  substantive  difference  among  the  leading 
contenders.  For  example,  several  dozen  paradigms  can  be  identified  for  command  and 
control.  The  alternative  paradigms  are  considered  by  Reference  41 ,  which  notes  that 
most  offer  little  in  the  way  of  new  problem  insight. 

In  time,  major  changes  are  likely  in  how  military  forces  are  organized  to  use 
information.  This  could  mean  evolution  of  collaborative  work  styles,  based  on  the  use 
of  team  work  stations  designed  around  advanced  displays.  Instead  of  hierarchies,  in 
which  bottlenecking  limits  flexibility,  future  systems  may  use  network  structures 
extending  across  the  ship's  life  lines.  For  example,  use  of  a  wide  area  net  to  provide 
fire  support  to  ground  forces  ashore  is  easily  envisioned.  A  third  key  source  of  change 


Common  Operating  Environment  -  A  ship  may  be  viewed  as  a  distributed  system  with  a  large 
array  of  components,  including  people  and  information  resources  as  well  as  equipment  items. 
What  turns  this  array  of  components  into  a  system  is  an  infrastructure  that  provides  facilities  for 
resource  management,  interconnection,  and  control  across  components.  Use  of  a  single 
infrastructure,  extending  across  all  mission  areas  and  functions,  would  result  in  a  common 
operating  environment  for  the  ship.  In  contrast,  today’s  ships  generally  have  different  (and 
noncompatible)  infrastructures  in  each  mission  area. 
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in  work  units  is  automation,  which  can  alter  task  allocation  between  humans  and 
machines  and  create  change  in  basic  work  processes  as  well.  To  prepare  the  way  for 
change,  it  is  important  to  establish  a  disciplined  process  for  managing  control  flexibility 
and  integrity  on  a  total  ship  basis. 
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CHAPTER  5 

IMPLICATIONS  FOR  DEVELOPMENT 


The  purpose  of  this  chapter  is  to  summarize  implications  of  the  overall  report  for 
definition  of  a  total  ship  system  engineering  process.  This  has  been  done  from  the 
viewpoint  of  the  development  organization  responsible  for  ship  design,  acquisition, 
construction,  and  support.  The  chief  concern  of  this  activity  must  be  to  ensure  that  all 
major  design  decisions  are  based  on  what's  best  for  the  Navy  as  a  whole,  rather  than 
what's  best  for  any  particular  component  or  class  of  systems.  This  makes  total  ship 
system  engineering  as  much  a  process  control  or  coordination  problem  as  it  is  a 
technical  problem. 


ENTERPRISE  CONCEPT 

Despite  the  many  twists  and  turns  in  acquisition  policy,  the  core  process  of  ship 
system  engineering  appears  to  have  been  fairly  stable  over  time.  The  core  process 
bears  some  resemblance  to  the  command  and  control  approach  pioneered  by  the 
General  Motors  Corporation  circa  1930.  Figure  15  outlines  the  main  characteristics  of 
this  approach  whose  overall  strategy  is  to  centralize  planning  and  decentralize 
execution.  As  practiced  by  industry,  the  process  emphasizes  vertical  integration  for  in- 
house  execution.  Up  to  70  percent  of  total  value  may  be  produced  by  in-house  activities. 


Main  Features 


^Centralized  Planning  & 
Decentralized  Execution 

In-House  Team  Leader 

•  Control  Design  Process 

•  Collocated  Design  Team 

•  Converging  Programs 

•  Built-in  Stovepipe  Effects 

^Many  External  Suppliers 

•  Detail  Design  &  Construction 

•  Many  Individual  Systems 

•  Integration  After  the  Fact 

^  •  Vulnerable  to  Buy-in 


FIGURE  15.  UNDERLYING  CONCEPT  OF  SHIP  ACQUISITION 

PROCESS 
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and  the  remaining  30  percent  typically  includes  bulk  materials  and  commodities  that  are 
widely  available.  A  central  engineering  staff  designs  components  and  gives  detailed 
drawings  to  the  suppliers  for  bid.  Bureaucracy  drives  relationships  among  the  in-house 
activities,  while  price  is  the  principal  factor  in  dealing  with  external  suppliers.  The 
acquisition  process  can  be  quite  vulnerable  to  buy-in. 

The  Office  of  the  Chief  of  Naval  Operations  (OPNAV)  provides  the  central 
planning  for  Navy  ships,  while  NAVSEA  executes  the  programs.  Ships  are  designed  by 
a  central  engineering  staff,  with  construction  by  a  privately  owned  shipyard.  Many  ship 
types  are  produced,  each  with  different  mission-critical  systems  but  many  common 
components  as  well.  A  typical  ship  has  thousands  of  functionally  complete  components 
and  scores  of  individual  systems,  each  designed  for  a  specific  purpose.  Scores  of 
acquisition  programs  and  thousands  of  suppliers  are  involved  in  creating  the 
components  and  delivering  them  to  the  shipyard.  The  scope  and  complexity  of  the 
enterprise*  tends  to  limit  use  of  common  designs  across  the  entire  Fleet. 

The  future  development  organization  should  be  structured  to  maximize  value 
delivered  to  mission  teams  on  a  life  cycle  basis.  While  no  specific  form  of  organization 
can  yet  be  recommended.  Figure  16  indicates  the  broad  pattern  envisioned.  In  fact, 
industry  has  turned  reinventing  the  enterprise  into  something  of  a  global  trend.  For  the 
most  successful  efforts,  thinking  in  terms  of  a  value  stream  has  been  the  crucial  first 
step.  This  drives  the  role  of  the  enterprise  leader,  who  must  act  to  shape  the 
overall  value  stream  and  not  the  value  added  by  direct  effort  alone.  This  causes  a  shift 
away  from  stovepipe  thinking  to  global  or  team  thinking.  In  particular,  greater  attention 


Key  Questions 


<=>  Establishing  User  Needs 

•  What  Must  War  Fighters  Do? 

•  Role  of  Surface  Ships 

t=C>  Role  of  Team  Leader; 

•  Vision  of  Total  Value  Stream 

•  Design  &  Budgeting  Process 

•  Integration  Strategy 

•  Mission-Critical  Systems 

O  Rethink  Chain  of  Supply 

•  Multiple  Streams  &  Sources 

•  Performance  Incentives 

•  Open  Specs  &  Standards 

,  •  Long  Term  Relationships 


FIGURE  16.  ORGANIZING  FOR  VALUE  STREAM  INTEGRATION 


An  enterprise  is  defined  as  not  a  single  activity  but  a  group  of  activities  working  together  to  supply 
a  good  or  service  in  a  way  that  creates  maximum  value  for  the  customer. 
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is  given  to  relationships  among  team  members,  and  to  the  transactions  between  them, 
which  often  have  the  most  potential  for  effectiveness  and  productivity  gains.  The  figure 
indicates  how  such  an  enterprise  might  be  structured.  It  has  three  layers, 
corresponding  to  value  delivery,  product  assembly,  and  component  input  activities. 

This  approach  is  widely  viewed  as  an  improved  model  for  design  of  large 
productive  systems.  The  original  implementation  is  credited  to  Eiji  Toyoda  and  Taiichi 
Ohno  and  sometimes  called  the  Toyota  Production  System.  The  basic  aim  was  to  form 
a  vast  group  of  suppliers  and  parts  plants  into  one  “machine”  by  producing  at  each  step 
only  those  parts  necessary  to  satisfy  immediate  demand  at  the  next  step.  The  final 
assembly  organization  functions  as  enterprise  leader.  Usually,  design  and 
production  of  components  that  tend  to  define  product  style  and  performance  are 
supplied  in  house.  Thus  the  enterprise  maintains  control  of  the  product  line,  but 
external  suppliers  provide  as  much  as  70  percent  of  total  value  added,  while  in-house 
activities  generate  only  30  percent. 

Suppliers  are  organized  into  functional  tiers,  with  multiple  products  and  multiple 
sources  in  each  tier.  First-tier  suppliers  have  an  integral  role  in  product  development 
and  are  assigned  a  whole  component  to  design.  The  suppliers  work  to  a  performance 
specification  for  a  system  which  must  work  in  harmony  with  other  components,  from 
other  suppliers.  Toyota  formed  first-tier  companies  by  spinning  off  in-house  divisions 
and  building  long-term  alliances  with  external  suppliers.  Production  is  typically  shared 
among  several  sources,  with  shares  fluctuating  up  or  down  according  to  performance. 

Second-tier  suppliers  tend  to  specialize  in  a  manufacturing  process.  A  first-tier 
supplier  might  design  an  alternator,  for  example,  and  buy  all  parts  from  second-tier 
suppliers.  The  latter  have  no  role  in  overall  product  design  but  may  produce  drawings 
for  individual  parts  and  have  firms  at  still  lower  tiers  produce  parts  to  those  drawings. 
Since  companies  at  this  level  normally  do  not  compete  for  specific  component  types, 
they  can  work  together  in  supplier  associations  for  the  purpose  of  sharing  information 
on  manufacturing  techniques. 

The  concept  of  operation  is  based  on  mutually  agreed  pricing,  strong  incentives 
for  performance  and  sharing  of  information,  and  long-term  relationships.  Direct 
competition  for  production  work  between  in-house  and  external  activities  is  avoided,  as 
it  tends  to  be  inefficient  and  unfair. 

Ships  are  a  capital  good,  so  the  organizational  model  from  industry  has  meaning 
for  ship  design,  acquisition,  and  construction.  The  basis  for  organization  is  then  to 
maximize  value  delivered  to  mission  teams  on  a  life  cycle  basis.  The  enterprise  leader 
is  viewed  as  an  integrated  program  team  with  both  Navy  and  builder  elements.  In 
essence,  the  lead  activity  controls  the  overall  design  process,  including  weight,  space 
and  cost  budgets;  the  strategy  for  integration  and  control  of  mission  capabilities;  and 
creation  of  the  mission-critical  systems  which  are  the  reason  for  taking  the  ship  to  sea. 
Beyond  this,  it  would  be  useful  to  rethink  the  entire  chain  of  supply,  seeking  to  adopt 
the  best  practices  from  major  enterprises  around  the  world.  At  each  tier,  supplier 
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associations  may  ba  formod  to  creata  and  to  promota  tha  usa  of  opan  spacifications 
and  standards.  Procass  improvamant  tachniquas  can  also  ba  sharad.  First-tiar 
suppliars  (major  systams)  should  participata  in  ovarall  ship  dasign.  Lowar-tiar  suppliars 
may  ba  ancouragad  to  participata  in  both  commarcial  and  dafansa  markats.  Idaally 
Navy  R&D  rasults  would  ba  sharad  among  sama-tiar  activitias. 


PROCESS  MODEL  FOR  SHIP  DESIGN,  ACQUISITION, 

AND  CONSTRUCTION 

Figura  17  shows  a  procass  rafaranca  modal  for  tha  davalopmant  taam  laadar.  It 
has  baan  organizad  into  fiva  layars,  with  aach  layar  rasponsibla  for  a  dafinad  sat  of 
systam  anginaaring  sarvicas.  A  similar  modal  for  softwara  davalopmant  in  larga-scala 
systams  is  considarad  in  Rafaranca  42.  Tha  modal  ancompassas  tha  antira  sat  of 
activitias  raquirad  to  craata  and  avolva  warships.  Tha  modal  framawork  consists  of  a 
sat  of  layarad  sarvicas.  Tha  framawork  is  flaxibla  and  rausabla,  as  individual  sarvicas 
can  ba  addad,  modifiad,  or  dalatad  from  aach  layar.  Tha  purposa  of  tha  rafaranca 
modal  is  not  to  maka  an  alraady  complax  problam  worsa,  but  to  clarify,  structura,  and 
rationaliza  tha  complaxity  inharant  in  tha  problam.  Systamatically  dafining  these 
services  as  organizational  layers  exposes  the  requirements  and  responsibilities  for  their 
definition.  Tha  modal  is  thus  a  step  toward  the  establishment  of  a  common  framawork 
for  total  ship  system  engineering. 


Layer  Descriptor  Services  Provided 


0 

Framework 

Services  used  in  defining  and  maintaining 
the  total  ship  system  engineering  process 

1 

Main 

Characteristics 

Defines  main  characteristics  for  the  ship 
as  a  system  of  systems 

2 

Coordination 

Coordinates  system  engineering  activity 
across  many  individual  systems 

3 

Individual 

Systems 

Defines  the  system  engineering  process  for 
individual  projects 

4 

Individual 

Products 

Describes  individual  work  products  created 
for  the  individual  systems 

FIGURE  17.  LAYERED  PROCESS  REFERENCE  MODEL 


Framework 

The  function  of  Layer  0  in  the  reference  model  is  to  provide  services  used  in 
defining  and  maintaining  the  process  of  interest.  As  indicated  above,  forming  a  process 
definition  team  is  recommended  as  the  starting  point  for  creation  of  a  total  ship  system 
engineering  process.  The  system  engineering  process  maturity  model.  Figure  18  and 
Reference  43,  offers  some  guidelines  for  process  definition  and  management.  As  a  look 
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at  the  figure  will  show,  recognizing  that  a  system  engineering  process  achieves  maturity 
in  stages  is  an  important  feature  of  the  guidelines.  Adopting  formal  methods  of  process 
definition  and  management  is  a  step  forward  from  the  ad  hoc  methods  normally 
employed.  Chapter  2  noted  the  chief  attributes  sought  in  the  process:  teamwork,  a 
system  of  systems  engineering  approach,  and  reliance  on  shared  concepts,  standards, 
and  tools  to  promote  design  integration. 


5  -  Optimizing 

Continuous 

Process  Improvement 
Focus  on  Feedback 

System  Problem  Prevention 
Technological  Innovation 

Process  Management 

4  -  Managed 

Quantitative 

Process  Data  Base 

Process  Measurement 

Problem  ID  &  Analysis 

Quantitative  Quality  Plans 

3  -  Defined 

Qualitative  •  Defined  & 
institutionalized 

Process  Improvement 

Group  Established 

Standards  and  Training 

Reviews  and  Testing 
Inter-Oiscipline  Coordination 

LC  Balanced  Product  Eng. 
Integrated  Systems  Mgt. 

2  -  Repeatable 

Intuitive  -  Process 
Depends  on  Individuals 

Focus  on 

Project  Management 

Requirements  Management 

Project  Planning  &  Tracking 
Configuration  Management 

Quality  Assurance 

Risk  Management 

1  -  Initial 

Ad  Hoc  /Unpredictable 

FIGURE  18.  SYSTEM  ENGINEERING  PROCESS  MATURITY  MODEL 


Teamwork.  The  first  and  most  important  step  is  probably  to  form  a  cadre  that  is  able  to 
consider  tradeoffs  from  a  total  ship  perspective.  This  calls  for  a  broader  perspective 
than  usual,  but  one  with  a  full  appreciation  for,  and  easy  access  to,  the  specialized 
technical  knowledge  of  functional  activities  and  the  warfighting  community.  In 
particular,  some  way  must  be  found  to  foster  and  control  dialog  between  the  different 
engineering  disciplines  involved.  A  team  effort  is  very  difficult  because  the  problem  is 
very  complex.  Adoption  of  a  common  language  and  pursuit  of  a  sustained  dialog  on 
problems  .and  opportunities  in  the  domain  can  help  a  cadre  learn  to  communicate  well 
enough  to  permit  good  teamwork. 

Once  a  coherent  framework  is  established  for  solving  key  problems  over  time, 
individuals  may  be  able  to  work  effectively  together  from  different  locations,  as  long  as 
frequent  communication  is  encouraged.  To  begin,  a  training  standard  for  the  cadre 
should  be  created  by  defining  an  agreed-upon  baseline  process. 

System  of  Systems  Framework.  This  refers  to  the  approach  of  Chapter  2.  Early  in  the 
process  of  cadre  building,  formation  of  a  strategy  team  should  also  be  considered. 

Such  a  team  can  help  articulate  a  domain  model  (Chapter  3),  creating  a  shared 
conceptual  framework  and  vocabulary  to  promote  cadre  formation.  The  first  attempts  to 
define  new  programs  involve  much  risk,  and  expert  advisors  (who  have  run  the  course 
successfully)  can  help  with  initial  plans  and  strategies.  In  early  plans  it  may  be 
necessary  to  anticipate  decisions  yet  unmade,  or  contingencies  yet  to  arise.  Because  a 
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ship  is  only  a  component  of  some  larger  system,  many  threads  must  be  woven  together 
to  formulate  an  overall  program  strategy. 

Information  Sharing,  As  suggested  by  Figure  19,  computer  networks  can  facilitate 
sharing  of  information  across  different  work  sites.  Today  it  is  possible  to  think  of  a  team 
being  brought  together  on  the  network,  sharing  data  and  holding  meetings  entirely  via 
the  network  using  common  design  aids  and  groupware.  A  virtual  team  is  an  integrated 


Operations 
&  Support 


I  Operations. 
Requirements^ri^^  &  Support- 


Collocated  Team 

Low  Automation  in  Design 
Voice-Based  Info  Sharing 
Site-Limited  Interactions 
One  Product  -  Many  Visions 


Virtual  Team  Approach 

•  Computer  Aided  Engineering 
Network-Based  info  Sharing 
Multiple  Sites  Interconnected 
One  Vision,  Fully  Integrated  Team 


FIGURE  19.  TEAM  WORK  ENVIRONMENT 


product  team  with  members  using  powerful  computer-aided  design  (CAD)  tools  in  their 
individual  workspaces  but  publishing  results  to  a  shared  information  base.  A 
coordination  service  may  exist  to  schedule  work,  report  progress,  notify  persons, 
authorize  work,  and  coordinate  execution  of  work  processes  without  the  need  for  face- 
to-face  meetings. 

Main  Characteristics 

The  function  of  Layer  1  in  the  reference  model  is  to  define  the  main 
characteristics  of  a  total  ship  system  engineering  process  using  Layer  0  services.  A 
key  principle  of  system  engineering  is  that  the  work  units  should  be  organized  around 
the  loosely  coupled  subsystems  formed  by  partitioning.  The  implication  is  that  a 
partitioning  for  total  ship  design  must  be  driven  first  and  foremost  by  operational 
considerations,  and  the  development  team  structured  accordingly,  rather  than  the  other 
way  around.  Those  activities  shown  in  Figure  20  are  seen  as  core  concerns  of  the 
development  team  leader.  They  parallel  the  ship  control  structure  shown  in  Figure  11. 
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Because  it  must  deal  with  acquisition  and  integration  of  individual  systems  as 
well  as  overall  ship  construction,  team  structure  is  a  bit  more  complicated  than  the 
operational  control  structure.  Once  a  basic  understanding  of  mission  teams  and  tasks 


LEVEL 

0 


LEVEL 

1 


LEVEL 

2 


FIGURE  20.  LAYERED  CONCEPT  FOR  TOTAL  SHIP  DEVELOPMENT 


has  been  established,  the  development  team  must  address  overall  ship  design,  the 
definition  of  backbone  control  structures,  and  the  definition  of  specific  operating 
processes,  adequate  to  meet  all  mission  needs.  Each  makes  a  key  contribution  to 
creation  of  a  total  ship  system  of  systems  from  the  host  of  individual  systems  which 
will  be  delivered  to  the  shipyard.  If  the  development  team  leader  activity  has  direct 
control  of  development  for  specific  mission-critical  systems  (i.e.,  new  capabilities 
central  to  the  ship’s  military  purpose),  they  may  fall  into  this  category  as  well. 

Mission  Teams  and  Tasks.  The  first  step  toward  defining  a  ship  must  be  to  consider 
how  warfighters  envision  its  use.  This  is  possible  only  if  experienced  operators  can 
be  directly  involved  in  the  creation  and  review  of  technical  planning  efforts.  Thus 
mission  teams  and  tasks  should  be  taken  as  the  starting  point  for  total  ship  system 
engineering.  Primary  emphasis  is  on  understanding  what  future  mission  teams 
must  do,  what  corresponding  warfare  processes  will  be  like,  and  what  information 
will  be  needed  to  execute  those  processes.  Success  has  been  achieved  only  if  (a) 
an  executable  system  design  description  exists  and  (b)  acceptance  criteria  for  the 
ship  have  been  nailed  down.  These  criteria  reflect  how  the  user  will  see  the  ship 
and  key  mission  systems  (and  interact  with  them)  as  the  tasks  laid  out  by  the 
concept  of  operations  are  performed.  This  may  include  tactical  and  technical 
experiments  to  develop  or  refine  system  concepts. 

It  is  important  to  ensure  an  effective  and  open  process  for  requirements 
consideration.  The  Mission  Needs  Statement  (MNS)  provides  a  baseline  for 
understanding  operational  requirements,  but  it  will  be  necessary  to  repeatedly 
refine,  clarify,  and  extend  this  baseline  as  development  activities  proceed.  The 
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system  engineering  process  must  provide  for  transformation  of  key  operational 
requirements  into  system  technical  requirements,  traceability  of  design  features  to 
intermediate  and  top-level  requirements,  and  management  of  requirements 
information.  The  integrity  of  the  system  engineering  process  depends  on  the 
handling  of  requirements:  it's  "garbage  in,  garbage  out."  Any  problems  should  be 
explored  and  resolved  through  dialog  with  OPNAV  and  Fleet  points  of  contact. 

Based  on  structure  and  content  of  the  requirements  data,  a  preliminary  functional 
description  should  then  be  constructed  for  each  major  mission  and  for  each 
backbone  area.  This  breakdown  should  include  no  more  than  three  levels  of  detail; 
i.e..  Tiers  0,  1 ,  and  2.  Where  possible,  measures  of  performance  traceable  to 
requirements  should  be  identified  for  each  function. 

Ship  Design.  This  activity  provides  the  design  studies  necessary  to  address  the 
questions  of  ship  form,  size,  and  essential  military  characteristics.  Speed, 
seakeeping,  strength,  stability,  and  style  are  the  major  naval  architecture  issues. 

These  characteristics  are  all  interrelated  and  dependent  on  overall  ship 
configuration  and  dimensions.  Accordingly,  the  design  activity  has  an  important  role 
in  establishing  configuration  baselines  for  the  ship  and  controls  the  general 
arrangement  to  achieve  spatial  and  mass  balance.  Thus  it  controls  the  design 
budgeting  process  for  the  ship,  possibly  including  signature  and  survivability  as  well 
as  the  usual  weight,  space,  moment,  and  cost  factors.  The  design  activity  also  has 
an  important  role  in  providing  the  physical  interfaces  (spatial,  mechanical,  and 
electrical)  necessary  for  the  many  individual  systems  packaged  into  a  multimission 
ship.  Virtually  all  the  resulting  information  finds  its  way  into  the  drawings  and 
specifications  used  to  select  and  provide  technical  direction  to  a  shipbuilder. 

The  overall  task  is  somewhat  complicated  by  the  existence  of  several  paradigms 
for  arriving  at  a  ship’s  general  physical  arrangement  and  breakdown  into  modules  for 
construction.  Each  involves  a  different  scheme  for  dealing  with  questions  of  spatial 
arrangement,  modularity,  affordability,  and  the  use  of  design  budgeting.  For  example, 
modularity  can  be  achieved  by  packaging  the  mission  capabilities  into  standard 
containers  (for  permanent  installation)  or  allocating  them  to  embarked  vehicles  or 
containers  that  can  be  moved  from  ship  to  ship. 

Backbone  Control  Structures.  This  activity  provides  for  integration  of  all  on-board 
control  resources,  in  effect  making  the  ship  a  real  "system  of  systems."  Ships  are 
composed  of  many  individual  systems.  The  systems  are  diverse  in  organization  and 
purpose  but  must  communicate  to  permit  coordinated  action  across  the  entire  ship. 

The  control  structure  must  include  mechanisms  to  facilitate  cooperation  among  the 
divergent  elements  and  parent  systems,  without  compromising  their  ability  to  perform 
their  designated  tasks.  Just  as  domain  models  permit  a  common  understanding  of 
goals  and  requirements  at  the  level  of  individual  systems,  the  backbones  permit  a 
shared  understanding  of  how  control  functions  and  interfaces  will  be  handled.  Their 
creation  will  establish  a  standard  for  services  available  to  individual  systems  and 
provide  guidelines  for  the  design  of  control  structures  and  interfaces  by  individual 
projects.  Standards  and  guidelines  created  in  this  manner  can  be  embedded  in  a 
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development  support  environment  for  use  at  the  project  level.  Creation  of  standard 
services  will  offer  potential  for  dealing  with  such  problems  as  configuration  flexibility, 
safety  certification,  fault  tolerance,  and  other  key  system  management  issues  on  a 
domainwide  basis. 

Operating  Processes.  In  developing  and  evaluating  ship  concepts,  boundary  conditions 
for  cost,  performance,  and  risk  versus  capability  and  affordability  drivers  must  be 
identified,  evaluated,  and  compared  as  a  system  package.  This  calls  for  a  total  ship 
perspective,  together  with  a  capability  for  detailed  analysis  of  ship  characteristics  and 
performance.  The  basic  purpose  of  this  activity  is  to  understand  what  mission  teams 
must  do  and  how  well  the  ship,  as  a  system  of  systems,  can  create  and  coordinate 
action  paths  adequate  to  meet  their  needs.  This  is  possible  only  if  experienced 
operators  can  be  directly  involved  in  efforts  to  define  (and  continually  improve)  primary 
warfighting  processes.  This  calls  for  a  variety  of  system  engineering  assessments,  but 
the  main  focus  should  be  on  process  engineering. 

The  role  envisioned  for  the  process  assessment  activity  demands  a  total  ship 
perspective  and  capabilities  for  detailed  analysis  of  ship  characteristics  and 
performance.  The  idea  is  not  to  displace  the  analysis  done  by  individual  programs  but 
to  integrate  available  information  for  assessment  of  major  ship  characteristics  at  the 
total  ship  and  force  levels  of  consideration.  The  potential  for  multipurpose  use  of 
sensors  and  weapons  makes  it  likely  that  new  warfighting  capabilities  will  be  identified 
in  such  efforts.  Each  design  alternative  must  be  examined  from  several  points  of  view, 
including  operational  effectiveness,  functional  and  physical  requirements,  potential  for 
upgrade,  manning  requirements,  readiness  for  transition  of  key  technologies  and 
systems,  external  interface  requirements  and  capabilities,  ability  to  support  and  control 
embarked  vehicles,  and  logistics  support  capabilities.  Suitable  MoEs  or  MoPs 
(measures  of  effectiveness  or  performance)  must  be  identified  for  conducting  systems 
analysis  and  tradeoff  studies  in  a  total  ship  context.  Specification  trees  may  be  used  to 
relate  concept  designs  to  (a)  performance  requirements  derived  from  top-down  mission 
analysis,  (b)  total  ship  analysis  and  engineering  efforts,  and  (c)  formulation  of 
acquisition  strategies. 

Coordination 

Layer  2  services  provide  for  coordination  of  development  activities  across  the 
many  individual  projects  which  contribute  to  a  shipbuilding  program.  Various  techni¬ 
ques  can  be  used  to  promote  system  engineering  communication  across  project  lines, 
as  shown  by  Figure  21.  The  most  powerful  are  (a)  use  of  common  reference  models 
and  engineering  environments;  (b)  engineering  demonstrations  and  experiments;  and 
(c)  an  agreed-upon  Type  A  specification.  Common  access  to  broad  design  concepts, 
and  shared  information  on  integration  opportunities,  may  also  prove  beneficial. 

Reference  models  can  help  to  establish  a  common  language  and  perspective 
across  the  community.  Engineering  experiments  are  crucial  because  they  receive  wide 
attention  within  the  technical  community.  A  ship-level  Type  A  specification  is  a  potential 
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vehicle  for  reaching  agreement  on  a  common  development  framework  with  all  those 
programs  supplying  individual  systems  for  ship  installation.  Terms  of  reference  for  any 
such  agreement  should  include  guidelines  for  consultation  in  areas  of  mutual  interest 
and  ground  rules  for  coordinating  action  on  matters  of  common  interest  to  all  parties. 
Coordinated  action  could  mean  the  use  of  shared  information  or  plans  (concurrent 
measures)  or  technical  efforts  (joint  measures)  defined  to  accomplish  specific  aims. 
While  several  ideas  are  offered  here,  the  executing  program  office  must  ultimately 
determine  coordination  measures  employed  and  how  to  implement  them. 


COOPERATION  LEVEL 

INSTRUMENTS 

Goal  Coordination 

•  Engineering  Principles 

•  Integration  Architectures 

Message-Passing 

•  Conferences  &  Publications 

•  Best  Practices  Exchanges 

•  Standards  Evaluation  Data 

Shared  Information 
Structures 

•  System  of  Common  Standards 

•  Integrated  Database  Systems 
-  Engineering  Networks 

Shared  Resources 

•  Joint  Projects  /  Experiments 

•  System  Integration  Technology 

•  Compliance  Evaluation  Teams 

FIGURE  21.  INSTRUMENTS  OF  WORK  COORDINATION 


The  recent  formation  of  two  new  NAVSEA  directorates  will  create  new 
opportunities  for  coordination  across  ship  acquisition  programs.  The  Directorate  for 
Surface  Combatants  will  be  responsible  for  cruisers,  destroyers,  frigates,  naval  guns, 
and  naval  surface  fire  support.  The  Directorate  for  Carriers,  Littoral  Warfare,  and 
Auxiliaries  will  be  responsible  for  carrier,  amphibious  assault,  auxiliary,  and  sealift  ship 
types.  (It  will  also  handle  the  remaining  nuclear  cruisers.)  The  Directorate  for  Theater 
Air  Defense  also  takes  on  broader  responsibilities. 

Individual  Systems 

Layer  3  services  define  the  system  engineering  processes  used  for  individual 
systems.  In  principle,  a  project  is  little  more  than  a  set  of  tools,  a  group  of  people,  and 
some  guidelines  by  which  they  work  together.  However,  many  different  approaches 
can  be  used  effectively,  and  it  is  generally  better  for  each  project  to  use  an  approach 
tailored  to  its  needs  than  to  enforce  a  "one  size  fits  all"  approach.  Assessing  cost  and 
capability  from  a  total  ship  perspective  then  becomes  difficult.  Recently  some 
companies  have  overcome  similar  problems  using  best  practices  standards  identified 
via  benchmarking.  There  is  also  considerable  potential  for  improvement  at  this  layer 
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through  use  of  networking,  simulation-based  design,  and  physics-based  modeling  and 
simulation  tools.  The  target  architecture  offers  a  medium  by  which  decisions  about  ship 
design  and  integration  strategies  can  be  made  and  used  to  define  a  standard  set  of 
services  available  to  the  individual  systems,  along  with  guidelines  for  their  use  by 
individual  projects.  The  results  can  be  used  to  create  a  development  environment  to 
support  engineering  at  the  individual  system  level.  This  can  be  viewed  as  a  "design 
backplane,"  allowing  individual  projects  to  adopt  a  toolkit  approach,  in  which  unique 
services  are  created  and  integrated  with  standard  services  to  form  complete  designs  for 
application  software,  equipment,  and  interfaces.  It  is  envisioned  that  computer-aided 
engineering,  design,  and  manufacturing  support  (CAE/CAD/CAM)  tools  will  be  used 
extensively  for  this  purpose.  Engineering  aids  can  be  used  for  analysis,  synthesis,  and 
simulation,  creating  a  powerful  off-line  system  for  exploratory  development  of  innovative 
design  solutions.  At  the  same  time,  the  backplane  will  incorporate  guidelines  to  assist 
individual  projects  in  achieving  a  common  look  and  feel  across  the  domain.  The 
potential  for  continuous  introduction  of  new  features  (through  modular  computer 
programs)  also  exists.  As  time  permits,  products  with  significant  reuse  potential  can  be 
folded  into  the  package  of  standard  services  made  available  by  the  development 
support  environment. 

Individual  Products 


Layer  4  services  are  used  to  describe  specific  work  products  of  all  kinds, 
essential  as  components  of  individual  systems.  The  services  involved  are  governed  by 
specifications  that  describe  technical  drawings,  documentation,  and  other  data  required 
for  product  design  and  production,  including  geometric  and  nongeometric  data  such  as 
form  features,  tolerances,  material  properties,  and  surfaces.  In  any  actual  shipbuilding 
program,  the  list  of  products  will  be  lengthy.  The  services  involved  are  defined  by 
individual  project  teams  in  accordance  with  higher  layers  of  the  process  model  and 
consist  of  specific  descriptions.  Services  (procedures,  standards,  and  tools)  available 
from  higher  layers  need  not  be  duplicated  at  this  level. 

The  standards  adopted  for  the  CALS  (Computer-Aided  Acquisition  and  Life 
Cycle  Support)  project  are  especially  relevant  in  this  area.  CALS  is  a  DoD  approach 
that  is  being  adopted  worldwide  by  industry  and  a  large  number  of  nations.  The 
strategy  is  intended  to  create  a  highly  integrated  and  nearly  paperless  process  for 
engineering,  manufacturing,  and  product  support  through  the  computer-aided  exchange 
of  information  in  digital  form.  Various  commercial  standards  are  used  toether  with  MIL- 
STD-1840  (Automated  Interchange  of  Technical  Information),  the  base  standard  that 
provides  the  overall  rules  for  organizing  files  of  digital  data  into  a  CALS-compliant 
product.  Ml L-STD-1 388-2  is  also  used  to  define  the  relational  database  management 
technology  for  CALS.  It  is  application  specific  to  Logistic  Support  Analysis  Records. 

IGES  (Initial  Graphics  Exchange  Specification,  ANSI  /  ASME  Y14.26M,  1989) 
and  STEP  (Standard  for  Exchange  of  Product  Data,  ISO  CD  10303)  are  both  applicable 
standards  cited  by  the  DoD  Technical  Reference  Model.  IGES  permits  the  exchange  of 
technical  two-  and  three-dimensional  drawings,  documentation,  and  other  data  required 
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for  products  design  and  manufacturing,  including  geometric  and  nongeometric  data 
such  as  form  features,  tolerances,  material  properties,  and  surfaces.  The  information 
typically  associated  with  CAD/CAM  can  be  described:  drawings,  wireframe  models, 
surfaces  and  solids.  IGES  has  some  limited  product  modeling  capabilities  but  its 
primary  purpose  is  to  convey  graphics  and  geometric  information.  STEP  is  capable  of 
completely  representing  product  data  over  its  entire  life  cycle.  This  representation  is 
suitable  for  file  exchange,  as  well  as  for  implementing  and  sharing  databases  of 
archived  information. 

Commercial  standards  for  electronic  data  interchange  (EDI)  may  also  be 
appropriate  at  this  layer.  EDI  services  are  used  to  create  an  electronic  environment  for 
conducting  commerce  and  achieving  significant  gains  in  responsiveness,  quality,  and 
savings  afforded  by  such  a  paperless  environment.  Examples  of  applications  include 
vendor  search  and  selection,  contract  award,  product  data,  payment  information,  and 
inventory  control.  ANSI  X.12  and  EDIFACT  (ISO  9735:1988)  are  competing  standards 
in  this  area. 

This  outline  of  Layer  4  services  (individual  products)  is  the  last  step  in  describing 
a  reference  model  for  total  ship  system  engineering.  The  primary  factor  in  model 
definition  is  value  delivered  to  mission  teams.  The  reference  framework  consists  of  a 
set  of  layered  services,  with  each  layer  responsible  for  a  defined  set  of  system 
engineering  services.  The  framework  is  flexible  and  reusable,  as  individual  services 
can  be  added,  modified,  or  deleted  from  each  layer.  A  team  leader  activity  is  assumed 
to  control  the  overall  design  process,  including  weight,  space,  and  cost  budgets;  the 
strategy  for  integration  and  control  of  mission  capabilities;  and  creation  of  the  mission- 
critical  systems  which  are  the  reason  for  taking  the  ship  to  sea.  Beyond  this,  it  appears 
that  the  entire  chain  of  supply  should  be  reinvented  to  incorporate  the  best  practices  of 
major  enterprises  around  the  world. 

Potential  obstacles  to  implementation  of  such  a  process  are  considered  below.  It 
should  be  noted  that  process  is  only  one  among  several  factors  that  drive  enterprise 
performance.  Other  important  factors  are  the  organizational  structure  used  to  carry  out 
the  process;  the  system  of  management,  including  incentive  structures;  and  the  unifying 
sense  of  purpose  and  direction  that  knits  the  people  involved  into  an  effective  team. 
Success  also  depends  on  the  kind  of  leadership  that  enables  us  to  cope  with  change 
and  create  the  kind  of  enterprise  that  can  succeed. 


TOWARD  IMPLEMENTATION 

This  report  begins  with  a  review  of  total  ship  engineering  concepts.  The  basics 
of  “system  of  systems”  engineering  are  given  in  Chapter  2.  Elements  of  a  domain 
reference  model  for  surface  combatants  are  considered  in  Chapter  3.  An  attempt  is 
made  in  Chapter  4  to  reinvent  surface  ship  control  structure,  and  the  current  chapter 
considers  a  matching  development  process.  Overall,  four  main  points  can  be  identified. 
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•  The  development  organization  must  be  tailored  to  the  desired  architecture  and 
engineering  process. 

The  first  consideration  in  total  ship  system  engineering  is  to  eliminate 
stovepiping.  In  the  existing  process  we  develop  many  independent  combat  and  ship 
systems  and  supply  them  as  GFE  to  builders.  Since  these  component  systems  are 
usually  developed  well  in  advance  of  ship  building,  physical  integration  is  about  all  that 
can  be  achieved,  and  the  ship  design  team  is  responsible  for  most  of  the  key  technical 
decisions.  Creating  a  totally  integrated  ship,  a  "system  of  systems,"  calls  for  an 
integration  strategy  that  extends  to  control  structures  and  operating  processes  as  well, 
and  can  occur  today  only  with  major  redesign  of  the  component  systems. 

In  this  area,  implementation  depends  on  two  essential  tasks.  One  is  to  begin 
forming  common  backbones  applicable  to  all  ship  classes.  The  "herringbone"  strategy 
demonstrated  by  the  Joint  Maritime  Command  Information  Systems  (JMCIS)  can  be 
used  to  migrate  from  today’s  many  component  programs  to  a  single  family  of  plant 
control,  combat  control,  and  information  management  backbones.  The  second  key  task 
is  to  work  with  element  developers  (e.g.,  radars,  launchers,  generators,  machinery)  to 
ensure  modularity  in  design.  A  total  ship  version  of  the  Affordability  Thru  Commonality 
program  should  be  sought,  placing  added  emphasis  on  modularity  in  ordnance  and 
computing  elements.  For  amphibious  ship  types,  cooperation  with  Marine  Corps 
programs  will  be  needed.  Forming  integrated  product  and  process  development  teams 
can  give  a  starting  point. 

These  changes  are  necessary  to  implement  a  total  ship  engineering  approach, 
but  they  must  be  accompanied  by  creation  of  an  organization  that  can  work  with 
OPNAV  and  the  Fleet  Commanders  in  Chief  (CINCs),  the  Marine  Corps,  and  the  other 
services  to  translate  joint  mission  needs  and  requirements  into  total  ship  concepts  and 
designs.  The  first  need  is  a  group  to  “engineer  the  force”--  that  is,  to  address  how  ships 
will  be  employed  together  with  other  joint  operating  forces  to  accomplish  broad  mission 
tasks.  In  part,  this  involves  identification  of  core  mission  teams  and  tasks  for  future 
ships  and  description  of  core  operating  processes.  This  calls  for  extensive  interaction 
with  warfighters.  Modeling,  assessment,  and  simulation-based  design  are  key 
activities. 

The  role  of  this  group  should  be  matched  to  that  of  N8  within  OPNAV.  Its 
primary  task  must  be  to  establish  a  total  ship  system  engineering  process  that  is  based 
on  a  clear  understanding  of  Navy  mission  tasks,  and  leads  to  a  total  Fleet  design  that 
reflects  a  practical  strategy  for  creating  and  sustaining  key  mission  capabilities.  The 
intent  is  to  attack  the  root  cause  of  stovepiping,  believed  to  be  the  absence  of  a  unifying 
sense  of  purpose  and  direction  among  peers  across  programs  and  functional 
specialties.  Change  begins  at  the  top. 


•  A  unifying  sense  of  purpose  and  direction  must  be  created  to  knit  the  people 
involved  into  an  effective  team. 
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Overall,  the  problem  is  perhaps  80  percent  organizational  and  cultural,  and  only 
about  20  percent  technical.  The  kind  of  leadership  that  enables  people  to  cope  with 
change  and  create  a  virtual  enterprise  from  a  large  array  of  participating  activities  is 
crucial  to  success.  This  means  the  following: 

0  Direction:  Setting  a  direction  means  creating  vision  and  strategies,  rather 
than  plans  and  budgets.  The  aim  is  to  describe  the  enterprise  in  terms  of 
what  it  should  become  in  the  long  run,  and  to  devise  a  feasible  way  of 
achieving  this  goal.  (We  can  agree  on  plans  and  budgets  but  still  get  in  each 
other’s  way.) 

o  Movement:  Getting  a  group  of  people  to  move  in  the  same  direction  takes 
more  than  organization.  It  means  communicating  a  vision  and  strategy  to 
anyone  who  can  help  or  block  their  achievement. 

o  Energy:  Just  as  direction  setting  identifies  an  appropriate  path  for  movement, 
and  effective  alignment  gets  people  moving  down  that  path,  successful 
motivation  generates  the  energy  to  overcome  obstacles.  This  depends  more 
on  appealing  to  basic  human  needs,  values,  and  emotions  via  informal 
networks  rather  than  formal  planning,  organization,  and  control. 

It  is  difficult  to  create  a  foundation  for  total  ship  system  engineering  that  spans  all 
the  disciplines  (technical  and  operational)  involved.  The  trouble  is  that  each  discipline 
has  its  own  conceptual  framework,  tailored  to  the  goals,  values,  and  character  of  its 
work  and  fundamental  to  effective  teamwork.  This  framework  is  passed  to  each 
generation  of  recruits  and  colors  perception  of  new  ideas,  sometimes  making  them 
seem  irrelevant  or  contrary  to  accepted  methods  or  bodies  of  knowledge.  Fortunately, 
this  is  an  obstacle  that  can  also  be  a  solution;  i.e.,  an  appropriate  conceptual 
framework  must  be  established  to  support  total  ship  system  engineering.  In  essence, 
this  report  is  aimed  at  producing  such  a  framework,  with  associated  design  concepts, 
standards,  and  tools. 


•  Backbones  are  the  key  to  building  warships  as  systems. 

The  advantages  of  a  common  backbone  apply  not  only  to  combat  control  (mission 
operations),  but  also  to  plant  control  and  readiness,  and  to  the  area  of  information 
management  as  well.  What  is  envisioned  is  a  generic  backbone  (with  variants  for  each 
area)  that  supports  design  for  modularity,  commonality,  and  the  sharing  of  functional 
resources  on  a  shipwide  basis.  The  generic  backbone  would  provide  the  following 
characteristics: 

o  Command  spaces  become  utilities,  tailorable  to  any  set  of  mission  teams  and 
tasks  which  may  be  operationally  required. 

o  Computing,  communication,  and  display  resources  are  managed  on  a 
shipwide  basis,  with  a  common  application  environment  maintained. 
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o  Readiness  assessment  and  resource  control  are  managed  on  a  shipwide 
basis. 

o  Life  cycle  costs  are  reduced  through  use  of  common  building  blocks  and 
open  systems  on  a  shipwide  basis  for  all  categories  of  systems,  with 
manning  and  parts  counts  held  to  minimum  levels. 

Total  ship  engineering  is  important  because  it  appears  feasible  to  arrive  at  an 
enduring  architecture  for  surface  combatants,  flexible  enough  to  permit  (a)  application 
to  a  variety  of  ship  types  and  designs;  (b)  insertion  of  new  functionality  as  warfighting 
systems  evolve;  and  (c)  incorporation  of  new  technology  as  it  becomes  available.  A 
key  aspect  of  modern  technology  is  the  potential  for  gains  in  capability  and  affordability 
through  the  sharing  of  resources  across  subsystem  and  element  boundaries. 
Resources  which  can  be  shared  in  this  way  include  sensors,  computers  and  displays; 
magazines  and  launchers;  ship  services  such  as  electrical  power;  and  computer 
applications.  The  idea  of  a  family  of  common  backbone  systems  is  promising,  although 
much  remains  to  be  done.  On  the  other  hand,  failure  to  design  surface  combatants  as 
systems  may  produce,  in  time,  a  Fleet  that  can’t  support  what  the  warfighters  must  do. 


•  Warfighters  must  be  involved  in  the  development  process. 

Today,  change  and  uncertainty  exist  in  every  part  of  the  process  by  which  naval 
forces  are  produced  and  employed.  Flexibility  is  a  major  consideration  in  building 
forces  to  cope  with  an  uncertain  future.  It  is  expected  that  flexibility  will  enable  US 
forces  to  respond  quickly  to  emerging  threats,  extend  US  reach  to  any  part  of  the  globe, 
and  adopt  new  technologies  with  ease.  Flexibility  takes  many  forms.  For  example,  a 
ship  may  be  equipped  to  perform  a  large  number  of  tasks  within  a  single  mission  area. 
Thus  an  aircraft  carrier  can  launch  and  recover  many  sorties  per  day  or  only  a  few,  as 
dictated  by  operational  tempo.  Another  form  of  flexibility  involves  the  performance  of 
tasks  in  multiple  mission  areas,  shifting  from  one  to  another  as  the  situation  demands. 
This  kind  of  flexibility  allows  a  deployed  force  to  handle  emerging  threats  without 
waiting  for  special  purpose  units,  and  is  often  associated  with  quick  response 
operations.  “Multimission”  ships  tend  to  be  large  and  expensive,  relative  to  single¬ 
mission  ships,  as  they  must  carry  a  variety  of  sensors  and  weapons.  Large  aircraft 
carriers  have  this  kind  of  flexibility  because  they  carry  a  mix  of  aircraft  types. 

Normally,  even  multimission  ships  have  a  limited  array  of  capabilities.  A  given 
design  could  perform  well  in  certain  scenarios  and  poorly  in  others.  Thus  a  third  kind  of 
flexibility  might  call  for  a  ship  that  can  tailor  its  capabilities  to  various  operating 
scenarios,  each  calling  for  a  different  mix.  Ideally,  ships  with  this  kind  of  flexibility  can 
cope  with  a  severe  threat  in  a  particular  mission  area,  or  a  diverse  threat  mix  that 
involves  several  mission  areas.  Tailored  flexibility  appears  to  offer  the  best  hope  for 
coping  with  the  current  era  of  uncertainty. 
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Having  acknowledged  the  importance  of  flexibility,  many  look  to  computers  and 
automation  as  the  key  to  improvement.  However,  the  brilliance  of  the  technology  tends 
to  obscure  the  importance  of  articulating  precisely  what  kind  of  flexibility  is  necessary 
and  defining  a  strategy  for  achieving  it.  The  bulk  of  lessons  learned  from  industry 
efforts  to  enhance  flexibility  through  computer  integration  indicates  that  success 
depends  more  on  people  than  any  technical  factor.  We  expect  experienced  teams  can 
handle  a  wider  range  of  tasks  than  novice  teams,  but  even  very  experienced  teams  can 
have  difficulty  adapting  to  change.  In  particular,  leadership  appears  to  play  a  key  role 
in  identifying  the  kind  of  flexibility  needed  and  when  it  is  appropriate.  This  is 
fundamental  in  a  practical  approach  to  automation. 

What  seems  most  promising,  for  improved  flexibility,  is  not  automation  to  replace 
people,  but  automation  that  will  assist  people  in  tailoring  systems  and  procedures  to  the 
changing  conditions.  More  is  gained  by  helping  people  to  make  better  decisions  than 
by  cutting  them  out  of  the  decision-making  process.  In  short,  since  we  are  not  likely  to 
know  in  advance  exactly  what  the  warfighters  will  be  called  on  to  do,  we  must  enable 
them  to  make  appropriate  decisions  in  the  field.  The  warfighter’s  role  must  be  clearly 
identified  in  overall  surface  ship  architectures,  and  mission  teams  must  be  provided  with 
the  information  needed  to  carry  out  that  role. 

This  calls  for  a  special  kind  of  automation.  In  humans,  the  autonomic  nervous 
system  works  without  regard  to  conscious  thought  processes  and  allows  key  control 
decisions  to  be  made  at  the  lowest  possible  level.  Flexible  response  is  achieved  by  use 
of  a  distributed  approach  in  making  decisions  about  system  structure.  Real  flexibility 
can  be  achieved  only  if  these  decisions  are  made  by  people  on  the  scene,  without 
having  to  consult  the  designers  who  correspond  to  the  brain  in  the  ship  engineering 
process.  Future  combatants  should  be  designed  so  the  necessary  judgments  (about 
mission  teams,  battle  doctrine,  information  flow  paths,  etc.)  are  made  by  the 
warfighters.  To  that  end,  it  is  essential  to  have  direct  involvement  by  experienced 
mission  teams  in  ship  design  and  development.  This  does  not  mean  less  rigor  in 
design  engineering;  it  may  mean  the  job  will  get  a  bit  tougher. 
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